Table of Contents

Next Page

Windows Vista Security: Securing Vista Against Malicious Attacks
Windows Vista Security: Securing Vista Against Malicious Attacks
byRoger A. GrimesandJesper M. Johansson
John Wiley & Sons 2007 (624 pages)
ISBN:9780470101551

Providing in-depth coverage of all significant security technologies in Windows Vista, this essential resource enables end-users and technical administrators to handle various security problems that still exist in Windows Vista as well as future threats.

Table of Contents
 | Windows Vista Security-Securing Vista Against Malicious Attacks
 | Foreword
 | Introduction
 | Part I - Introducing Windows Vista
 | Chapter 1 | - | New Security Features
 | Chapter 2 | - | How Hackers Attack
 | Chapter 3 | - | Windows Infrastructure
 | Part II - Host-Based Security
 | Chapter 4 | - | User Account Control
 | Chapter 5 | - | Managing Access Control
 | Chapter 6 | - | Application Security
 | Chapter 7 | - | Vista Client Protection
 | Part III - Securing Internet and E-mail Access
 | Chapter 8 | - | Securing Internet Explorer
 | Chapter 9 | - | Introducing IIS 7
 | Chapter 10 | - | Protecting E-mail
 | Part IV - Securing Windows Networks
 | Chapter 11 | - | Managing Windows Firewall
 | Chapter 12 | - | Server and Domain Isolation
 | Chapter 13 | - | Wireless Security
 | Part V - Group Policy and Best Practices
 | Chapter 14 | - | Using Group Policy
 | Chapter 15 | - | Thinking about Security
 | Appendix A | - | Building a Windows PE Boot Disk
 | Appendix B | - | References
 | Index
 | List of Figures
 | List of Tables
 | List of Sidebars

Next Page


Back Cover

Previous Page
Next Page

Back Cover

It's not the computer. The hacker's first target is YOU!

A dirty little secret that vendors don't want you to know is that good computer security doesn't cost a thing. Any solution you can buy is guaranteed to fail. Malicious hackers use this fact to their advantage. Real security is gained by understanding the enemy's tactics and offsetting them with appropriate and consistently applied Windows settings. These expert authors realize that an effective strategy is two parts technology and one part psychology. Along with learning about Vista's new security features (such as UAC, integrity controls, BitLocker, Protected Mode, and IIS 7), learn common-sense recommendations that will immediately provide reliable value.

Vista Security Tips

  • Have a healthy sense of paranoia
  • Understand and apply the basics properly
  • Use longer passwords. No, longer than that
  • Use admin privilege very sparingly
  • Don't believe Internet Explorer Protected Mode will stop all attacks
  • Don't believe DEP can stop all attacks
  • Don't believe any technology can stop all attacks

About the Authors

Roger A. Grimes (CPA, CISSP, CEH, CISA, MCSE: Security) is a 20-year Windows security veteran and four-time Microsoft Most Valuable Professional (MVP) for Windows security. Roger currently works for the Microsoft ACE Services team as a senior security consultant, but in the past has worked for Foundstone and consulted for dozens of the world's largest companies. This is Roger's seventh book on computer security. He is the author of over 200 magazine articles and he is the InfoWorld magazine security columnist and blogger.

Jesper M. Johansson is a security architect focusing on software security. Prior to his current position, he was an assistant professor at Boston University, and then a Senior Security Strategist at Microsoft where he worked in the Secure Windows Initiative and Trustworthy Computing Groups. He has worked in security for about 20 years and is the author of many articles and two books on the topic. He has delivered hundreds of presentations on security on every continent except Antarctica and South America and is a contributing editor to TechNet Magazine. Dr. Johansson has a Ph.D. in Management Information Systems and is a Certified Information Systems Security Professional (CISSP) and a certified Information Systems Security Architecture Professional (ISSAP).

Previous Page


Windows Vista Security-Securing Vista Against Malicious Attacks

Roger A. Grimes
Jesper M. Johansson

Wiley Publishing, Inc.

Published by
Wiley Publishing, Inc.
10475 Crosspoint Boulevard
Indianapolis, IN 46256
http://www.wiley.com

© 2007 Wiley Publishing, Inc., Indianapolis, Indiana.

978-0-470-10155-1

10 9 8 7 6 5 4 3 2 1

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (800) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002.

Library of Congress Cataloging-in-Publication Data

Grimes, Roger A.
Windows vista security: securing vista against malicious attacks / Roger A. Grimes, Jesper M. Johansson.
p. cm.
Includes bibliographical references and index.
ISBN 978-0-470-10155-1 (paper/website)
1. Microsoft Windows (Computer file) 2. Computer security. I. Johansson, Jesper M. II. Title. QA76.9.A25G777 2007
005.8–dc22

2007020135

Trademarks: Wiley, the Wiley logo, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. Microsoft and Windows Vista are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

I would like to dedicate this book to my beautiful wife, Tricia, who has been my biggest fan, constant rock, and who has never once complained about my insanely long work hours or world travel commitments.

-Roger

I dedicate this book to my lovely and talented wife, Jennifer, who although she may complain occasionally about long working hours, is always right!

-Jesper

About the Authors

Roger A. Grimes (CPA, CISSP, CEH, CISA, MCSE: Security) is a 20-year Windows security veteran and four-time Microsoft Most Valuable Professional (MVP) for Windows security. Roger currently works for the Microsoft ACE Services team as a senior security consultant, but in the past has worked for Foundstone and consulted for dozens of the world's largest companies. This is Roger's seventh book on computer security. He is the author of over 200 magazine articles and he is the InfoWorld magazine security columnist and blogger.

Jesper M. Johansson is a security architect focusing on software security. Prior to his current position, he was an assistant professor at Boston University, and then a Senior Security Strategist at Microsoft where he worked in the Secure Windows Initiative and Trustworthy Computing Groups. He has worked in security for about 20 years and is the author of many articles and two books on the topic. He has delivered hundreds of presentations on security on every continent except Antarctica and South America and is a contributing editor to TechNet Magazine. Dr. Johansson has a Ph.D. in Management Information Systems and is a Certified Information Systems Security Professional (CISSP) and a certified Information Systems Security Architecture Professional (ISSAP). When he is not working on information security, he teaches scuba diving and enjoys life with less travel and more family.

Credits

Executive Editor
Carol Long

Development Editor
Kelly Talbot

Technical Editor
Alun Jones

Production Editor
Christine O'Connor

Copy Editor
Nancy Rapoport

Editorial Manager
Mary Beth Wakefield

Production Manager
Tim Tate

Vice President and Executive Group Publisher Richard Swadley

Vice President and Executive Publisher Joseph B. Wikert

Project Coordinator
Lynsey Osborn

Compositor
Craig Woods, Happenstance Type-O-Rama

Proofreader
Sossity Smith

Indexer
Robert Swanson

Anniversary Logo Design
Richard Pacifico

Acknowledgments

I wish to thank all the teachers in my 20-year computer security career, especially the other humbling MVP security contributors, friend Mark Minasi, the public security mailing lists, and friends in the industry. Twenty years ago I thought I knew everything; now I know I only know what fits on the end of a fingernail.

- Roger

I wish to thank the various people at Microsoft who helped get me information for my chapters, including Sarah Wahlert, Darren Canavor, Steve Hiskey, Eran Yariv, Eric Fitzgerald, Michael Kleef, and Peter Brundrett. I would also like to thank my current and former coworkers at Amazon, as well as my friends Susan Bradley and Alun Jones, who tirelessly reviewed everything we threw at them. Finally, I must not forget Jeremy Moskowitz, Jimmy Anderson, Mike Smith-Lonergan, and Mark Burnett, who provided valuable feedback on their respective areas of expertise.

- Jesper


Foreword

2003 was a turning point year for the Internet. In January of that year, the Slammer worm crippled many systems all over the world. A few months later Windows Server 2003 was released. It was the first operating system to have gone through an entirely new model for developing secure software-what was later to become known as the Security Development Lifecycle (SDL).

A year prior to the release of Windows Server 2003, Microsoft made a concerted effort in the Windows division to find as many security bugs in the new operating system as possible by assigning most of the engineers in the Windows division to a six-week task of finding and fixing bugs. This was the now infamous "security push." Many bugs were found in this effort but the current set of tools and the manual efforts involved also meant that some were missed. In addition, the bad intentioned people were increasing their efforts exponentially on finding new exploits. New ways to exploit systems were being discovered almost weekly.

The security push taught Microsoft that:

  1. security was no longer optional in products,

  2. Microsoft needed to take a leadership position in delivering more secure products,

  3. tools and processes needed to change to find more of the bugs upfront in the development cycle,

  4. taking an entire division offline to hunt for them was not the most effective method as software continually evolves.

We learned that security improvements are a journey that never ends; therefore we cannot treat this issue as a destination that can be reached in six weeks.

In August 2003, the Blaster worm was unleashed. Although Windows Server 2003 was affected by the bug, changes made during the security push stopped the Blaster worm itself from spreading through that version of the operating system. This was proof positive that focusing on security made a difference although it also proved that more work needed to be done.

By late summer 2003, Microsoft knew something had to be done differently because reacting to each exploit individually was not going to scale and we needed to proactively build defenses into our existing OS products and "change the game" as we called in our next release of the OS. A decision was made to retrofit significant changes into the existing OS releases and shore up Windows XP and Windows Server 2003. We had to make it much harder for those with bad intentions to exploit the installed base of Windows. This resulted in the creation of Windows XP Service Pack 2 (XPSP2) and Windows Server 2003 Service Pack 1 (W2003SP1). Although these releases were called Service Packs, very significant changes were made to both of these releases focused on "getting ahead in the game" by using generic solutions to proactively render whole classes of exploits useless. Two simple examples of this are turning the Windows firewall on by default and configuring the system to automatically download and install fixes to known exploits.

It was decided while XPSP2 was under development that there needed to be additional "game changing" efforts to not just get ahead in the current game, but to change the game on those people in the world wishing to do digital harm by exploiting vulnerabilities in software. Because of the extensive architectural changes needed, these changes had to be done in the new version of the operating system under development, which eventually became Windows Vista. Broad security efforts within the Windows division were redoubled and many people were hired or reorganized to work on the security of the new operating system. Forums were created to look at all new ideas and architectures, existing processes were changed to include security check points throughout, testing processes were enhanced to include threat models and security testing in all stages of development, new static code analysis tools were developed to scan code looking for vulnerabilities, new features were added, and the strategy for the operating system was changed. All in all, it was a huge effort and a new way of building more secure systems at Microsoft.

These changes were not free. On November 8, 2006, Windows Vista was finally released; several years delayed but a much better product security-wise than had it shipped when it was originally supposed to. This book is about the product that resulted.

The authors are well suited to writing this book. Roger is a long-time Windows analyst, a former Microsoft Security MVP, and a current member of the ACE Team at Microsoft-a team focusing on internal secure software development consulting. Jesper is a veteran of the original Windows Security Push, and a former member of the Secure Windows Initiative, the team that worked on Windows Server 2003 and Windows Vista to find and fix security issues.

Even though I have since left Microsoft, I am immensely proud of the accomplishments of the Windows Division during my tenure there. Windows Vista is the best operating system Microsoft has ever produced, and it is produced by one of the most dedicated teams I have ever had the privilege to manage. Vista is not just about security but also includes many new amazing features in all aspects of the operating system. Never once did I have to question the team's commitment to security in the product and I was honored to work with some of best security professionals in the industry. Every day I was amazed by the team's creativity in coming up with solutions that would truly enable Windows Vista to change the game.

I wouldn't trade anything for the opportunity I had to be part of all those meetings, putting in all that effort, living through all that pain, and attending all those reviews with my manager, Jim Allchin, where he consistently challenged us to build great security solutions in his own unique way. The result was worth it for the millions of Windows customers, and the memories I have are priceless.

In my opinion, Windows Vista is certainly the most secure operating system Microsoft has ever produced. Quality and security really do go hand in hand and Vista has both. The book you are holding in your hand gives you the knowledge you need to harness the security of the new flagship operating system from Microsoft. Now stop reading this, and get on with the exploration!

COSD Rocks!

Brian Valentine
Senior Vice President, http://www.Amazon.com
Formerly:
Senior Vice President, Core Operating Systems Division, Microsoft


Introduction

Overview

A lot of people believe that Microsoft Windows security sucks and that Microsoft is by far the worst of all software vendors! Many of them back this up with anecdotal evidence from the late 1990s. Most of them have simply refused to believe that the company could actually have changed.

The truth is that the state of almost all software security is very poor. In comparison with most software development organizations, Microsoft is actually doing a pretty good job. In the first 90 days after its release, there were five announced vulnerabilities in Windows Vista, whereof one had been fixed. (These figures are from Jeff Jones, a director at Microsoft, who, in spite of his employment, tends to be quite objective. Read his entire report at http://www.blogs.csoonline.com/windows_vista_90_day_vulnerability_report.) Five vulnerabilities in 90 days may not sound so good, but compare that to Windows XP. Windows XP had 18 announced vulnerabilities and 14 fixes in the first 90 days. Clearly, Windows Vista is an improvement. How about other vendors though? Well, there were 11 patches for 36 vulnerabilities in Red Hat Enterprise Linux 5 on the day it shipped. As of the time of this writing, it had not been out for 90 days yet so it is hard to say whether that trend is better than Red Hat Enterprise Linux 4, which had 181 fixes and an additional 85 unpatched vulnerabilities in the first 90 days. Apple fared far better, as it is quick to point out. In the first 90 days of Mac OS X 10.4 there were 20 vulnerabilities fixed and an additional 17 without a fix. Imagine that, on a pure vulnerability count, Windows Vista is actually the best of the bunch and even Windows XP beat Mac OS X.

However, vulnerability counts are clearly not the best measure of security. The easiest way to decrease vulnerability counts is to remove functionality. One of our favorite operating systems is OpenBSD. It has had extremely few vulnerabilities, but it doesn't have near the amount of functionality that Windows has. By design, OpenBSD provides a very small percentage of the services that Windows provides. OpenBSD is a great operating system for technical computer users who value security over functionality to an intractable degree, but it is too hard to install and configure for the average computer user. The harder security challenge is to appropriately secure a widely functional system while not making it incredibly difficult to use. In spite of what the competition may claim, Windows Vista actually has a wide-ranging set of security features, and if you understand how to use them, they work extremely well. In Windows Vista, security is by and large enabled by default, making it all that much more important to read this book to learn how to use it.

The truth is that any OS, Windows or not, can be secure or insecure. Follow the vendor's instructions, keep it patched, don't click on things you shouldn't, and you will be fairly well protected. But always, if I can get you to click on my untrusted executable, it's always game over no matter what OS you are using.

Microsoft, as a for-profit company, has aimed to make a sufficiently secure operating system that even your average grandmother can install and use, and that provides a great platform for third-party software. And regarding that objective, the authors feel it does a pretty good job. To be secure doesn't take rocket-science, or even an anti-malware product, IDS, or host-based firewall. The basics of computer security, which apply to any OS, including Windows Vista, are these:

  • Keep the OS and all applications fully patched.

  • Don't be logged in with elevated privileges when not needed.

  • Use long passwords (eight characters or longer).

  • Don't click on file attachments or links that you should not click on, and don't visit Web sites you shouldn't.

  • Remove unnecessary software and services, and don't install untrusted software.

  • Implement the appropriate permissions and privileges.

  • Practice risk analysis.

  • Have a healthy sense of paranoia and question the legitimacy of things you are presented with.

Yes, there are dozens of other good security tips, but these eight are the most important. If you and your company follow these eight simple security rules, you will be better protected than 99 percent of the companies out there.

Perplexingly, instead of clients asking us how to implement these simple principles, the authors are often asked to help set up complex security systems (such as PKI, identity management systems, security automation, and so on), while the clients requesting the help don't do the basics properly. It's like asking for a castle surrounded by a moat, and then putting a motion sensor on the outside of the drawbridge, storing the crown jewels in the courtyard, and keeping the gate open on purpose.

People don't want to do the basics. It is too difficult to learn about how things work. People want the big blue "secure me now" button. Unfortunately, that button does not exist. Trust us-if it did, Microsoft would already be selling it! In the quest for the big blue button, people spend money on antivirus software, firewalls, IDSs, and lots of other security technologies and then wonder why they keep on failing, why none of them protect against attacks that fundamentally target humans, not computers. It's befuddling to know and recommend the real solutions for over two decades, only to have people ignore the basics. In reality, what is needed is a good understanding of how the technology works and a critical mind to apply to the question of how, or whether, to use it.

That is why the authors decided to write this book: to impart as much of this information as possible to you. Windows Vista will be hacked, just like all its competition. Windows Vista will be more secure than previous versions of Windows, but it will still be subject to myriad user attacks, probably a few browser vulnerabilities, and more than a few other attacks scattered throughout. But, if you understand how Windows Vista works and how to use it, it will be better than any comparable OS that has come before it because it was designed to meet threats that will occur in the next two to five years, not those that were relevant in 1999. And, in spite of the fact that it often feels like Microsoft treats security as a marketing issue, at least it does not demonstrate a fundamental lack of awareness of the problem by claiming that security is only a problem for someone else (http://www.news.com.com/2061-11199_3-6127343.html). Whatever you want to say, a lot of people at Microsoft take security very seriously, and the fruits of their labors are described in this book.

Readers can read this book to learn about the new security features in Windows Vista (we cover more than 1,000 changes), plus learn more about the basics and how to implement them, and read the collective security advice from two of the world's most knowledgeable Windows security experts. After reading this book, readers will have the knowledge and practical tools to secure any environment including Windows Vista.


Overview of the Book and Technology

This book introduces the reader to Windows Vista security. Every new version of Windows has included some new security measures, but never has the difference between versions been as dramatic as it is with Windows Vista.


How This Book Is Organized

The book is organized into 5 parts with 15 chapters:

  • Part I, "Introducing Windows Vista"

  • Part II, "Host-Based Security"

  • Part III, "Securing Internet and E-mail Access"

  • Part IV, "Securing Windows Networks"

  • Part V, "Group Policy and Best Practices"

Part I is an overview of the new security features of Windows Vista, how malicious hackers hack, and how Windows functions in general.

Part II focuses on general host-based security controls, such as User Account Control, Windows Defender, and application security. Because most of today's computer attacks use client-side, host-based vectors, this is an especially important section.

Part III focuses on securing Internet Explorer and e-mail from the client perspective and IIS from the server perspective. Browser and e-mail programs are involved in most of today's malicious exploits. Part III introduces Internet Explorer 7, Windows Mail, and IIS 7.

Part IV discusses the improved Windows Firewall, IPsec, and wireless security. Part IV also includes a section about one of the most promising network security techniques available today-Server and Domain Isolation.

Part V focuses on automating security using group policy and finishes in Chapter 15 with point-counterpoint discussions between the two authors. The last chapter summarizes the authors' strongest held defense beliefs and recommendations.

Chapter 1, "New Security Features"

Chapter 1 begins by discussing, sometimes in detail, the most significant new security changes to Windows Vista from previous Windows versions. It discusses dozens of new security features. It is a quick, one-stop, shop chapter for readers who want to quickly learn what new features Vista has.

Chapter 2, "How Hackers Attack"

In order to defend appropriately, you must understand what you are up against. Contrary to popular belief, most attacks on Windows computers are not one-off attacks by dedicated human attackers. Instead, the vast majority of attacks are automated from malware programs. However, automated or not, both human attackers and automated malware use similar hacking techniques. Chapter 2 summarizes the various forms of automated malware and discusses the main hacking techniques.

Chapter 3, "Windows Infrastructure"

Microsoft Windows is a complex operating system. Chapter 3 attempts to demystify some of the lesser known operational infrastructures. Essentially, this chapter explains how Windows really works. It covers security principals, rights, privileges, permissions, objects, delegation, and impersonation. After reading this chapter, the average Windows administrator should understand more about Windows and how it operates than ever before.

Chapter 4, "User Account Control"

User Account Control (UAC), more than any other feature, is the face of Windows Vista security. Chapter 4 discusses UAC in detail, talking about what it is, why it was created, and what it isn't made to do. UAC is a great security addition to the Windows family, but not for the reasons most people first believe. Many users who don't understand its role may disable it or, just as bad, ascribe it too much importance.

Chapter 5, "Managing Access Control"

This chapter discusses file permissions, share permissions, and Registry permissions. You will learn the changes in access control lists and group permissions. You will also learn how to manage ACLs.

Chapter 6, "Application Security"

Chapter 6 covers Windows Vista's new application security features, and how administrators and end users should approach and configure applications. Legacy applications could have a hard time working on Windows Vista without a bit of tweaking. This chapter covers manifest files, elevation levels, virtualization, and service hardening.

Chapter 7, "Vista Client Protection"

Chapter 7 covers Microsoft's newest client-side initiatives against malware programs, including the Malicious Software Removal Tool, Security Center, Windows Defender, Windows Live OneCare, and Microsoft Forefront Client Security.

Chapter 8, "Securing Internet Explorer"

Internet Explorer is the most attacked software program on the planet. It is almost single-handedly responsible (together with IIS) for Microsoft's bad reputation on security around the turn of the century. The continued assault on IE and multiple vulnerabilities creates uncertainty and doubt among customers about Microsoft's ongoing commitment to security. With this in mind, Microsoft released Internet Explorer 7 and a Vista-only security protection, called Protected Mode, to quiet the critics, at least for a while. By the time we wrote this, Internet Explorer 7 has proven to be more secure and robust than its predecessor versions but only time will tell how well it will hold up.

Chapter 9, "Introducing IIS 7"

IIS 6 was a tremendous security success for Microsoft. IIS 7 builds on that success and attempts to make IIS more granular, and in the process, even more secure. Most people expected IIS 7 to be released in Microsoft's forthcoming server product, but it makes its first appearance in Windows Vista. Chapter 9 covers all the significant security features of IIS 7 and gives step-by-step instructions for building a hardened web server.

Chapter 10, "Protecting E-mail"

Windows Mail replaces Outlook Express as Windows' new e-mail client. Redesigned from the ground up, Windows Mail is intended to be a more secure e-mail client comparable to the other security improvements in Vista. Read Chapter 10 to learn more about Windows Mail and its new security features.

Chapter 11, "Managing Windows Firewall"

Windows Vista contains a significantly improved Windows Firewall. Besides new configuration GUIs and command-line controls, Windows Firewall has outbound blocking and better integration with IPsec. Chapter 11 will cover the new, improved Windows Firewall.

Chapter 12, "Server and Domain Isolation"

Host-based and perimeter-based firewalls are not enough protection these days for enterprise networks. Essentially, an administrator must map all the legitimate traffic that should be allowed between various hosts and deny all traffic that isn't specifically allowed. Chapter 12 covers domain isolation and IPsec.

Chapter 13, "Wireless Security"

Almost every corporate environment, and home it seems, has a wireless network. Wired Equivalent Privacy (WEP) has been replaced by stronger WPA, WPA2, and 802.11i security. Chapter 13 covers the most popular Wi-Fi technologies, threats to wireless networks, and wireless security recommendations.

Chapter 14, "Using Group Policy"

If security isn't automated, it will most likely not be done. Windows Vista is seeing what is likely the most significant upgrade to Group Policy since Group Policy was introduced with Windows 2000. In this chapter, we go over the new and updated features, as well as a selection of the 812 new Group Policy settings.

Chapter 15 "Thinking About Security"

Chapter 15 includes a point-counterpoint discussion between the two authors on what they feel are the most significant security recommendations an administrator can implement. This chapter captures the collective thoughts from two industry veterans of 20 years, and security tips learned as Microsoft insiders and outsiders. Much of the practical advice dispensed here will be found in no other book.

Appendixes

Appendix A covers step-by-step instructions for making a Windows PE boot disk. Appendix B lists many of the recommended resources the authors used in preparing this book.

The 15 chapters of Windows Vista Security: Securing Vista Against Malicious Attacks provide a solid introduction to the new security features in Windows Vista and make recommendation after recommendation for the reader to implement. Most chapters, where it makes sense, contain a Best Practices recommendation section so the reader can quickly review the most important points and use them in their environments.

All readers should start with Chapter 1, "New Security Features," to get a quick understanding of all the new features in Windows Vista. Readers who already understand hacking and malware methodology can skip Chapter 2, "How Hackers Attack," although there are guaranteed to be fine points that can benefit any administrator. Chapter 3, "Windows Infrastructure," should be read by all readers to make sure they have a common, strong foundation of the basic Windows infrastructure concepts. Likewise, given the pervasive nature and strategic importance of UAC, it should be considered required reading as well.

The chapters in Part II, "Host-Based Security," and Part III, "Securing Internet and E-mail Access" should be read by all readers, as these chapters cover many of the core components of Windows Vista. Parts II and III will be of special interest to security and Windows administrators, and desktop support technicians. Part IV, "Securing Windows Networks," will be of the most interest to administrators charged with protecting Windows networks, as the title implies. Chapter 14 will be of the most interest to Active Directory group policy administrators, although much of what is recommended also applies to local security policy. Last, Chapter 15, "Thinking about Security," should be read by all readers. It contains advanced expertise and recommendations.


Who Should Read This Book

Windows Vista Security: Securing Vista Against Malicious Attacks is intended to teach something to administrators at every level, but is optimized for those with a little bit of experience in administering Windows. While a beginning administrator can easily implement any of the discussed techniques, it helps to have a firm foundation of Windows basic fundamentals, especially as they apply in Windows 2000 or later, before reading any book of this nature. While each chapter covers the major topics from the beginning forward, some related topics, such as TCP/IP, are not intended to be the focus of this book and will not be discussed in totality. Other huge topics, such as group policy, focus on the additions and changes as they relate to Windows Vista.


Tools You Will Need

All the programs and tools discussed or recommended in this book are installed with Windows Vista or are readily available for downloading (most for free) on the Internet.


What's on the Web Site

The Web site contains a few tools that you may find useful. One of them allows you to elevate any application from a command prompt and can also be used to launch applications with low integrity for testing purposes. There are also some scripts that give you information useful for troubleshooting and configuring the system. The Web site also has a document that contains details on the security settings of every service that ships in Windows Vista. We were originally intending for it to be an appendix, but it is several hundred pages long. You will find the Web site at http://www.wiley.com/go/windowsvistasecurity.


Summary

It is the authors' hope that the readers of Windows Vista Security: Securing Vista Against Malicious Attacks come to be among the most informed Windows administrators in the business. After finishing this book, readers should understand the strengths and weaknesses of Windows Vista, and of computer security in general. Along with all the new material presented, we hope that you walk away with answers to many questions that you've had for years about existing technologies and techniques. Last, we hope to impart to the reader a healthy dose of security skepticism, both directed toward all the glowing Windows Vista marketing literature and toward its critics. We firmly believe that Windows Vista is among the most readily secured operating systems for PCs and is highly appropriate for most networks and users.


Part I: Introducing Windows Vista

Chapter List

Chapter 1: New Security Features
Chapter 2: How Hackers Attack
Chapter 3: Windows Infrastructure


Chapter 1: New Security Features

It is not hyperbole to say that almost every line of Windows Vista code has an increased focus on security. Each subsequent version of the Windows operating system (OS) has been demonstrably more secure than the previous one. Windows Vista is no different. It contains hundreds of new security features, and what isn't completely new is improved. Windows Vista includes new security mechanisms, improved versions of older features, enhanced integration, improved interfaces, and stronger default settings. Chapter 1 will cover the most significant new and improved Vista security settings. It's a long chapter, but worth the read.

Security Development Lifecycle

Not surprisingly, the increased security focus of Windows Vista began in the planning stages. Windows Vista is the first Microsoft OS to be built from the ground up using the Security Development Lifecycle (SDL). SDL is designed to infuse security into software development, starting long before the first line of code is written.

Crucial to SDL is the identification of potential threats using a method called threat modeling, where every possible threat that can be imagined is documented. The lack of a coherent threat model led to most of the security design flaws of past Windows operating systems.

This time around, Microsoft employees and external security reviewers identified over 1,400 unique threat modeling scenarios. A large majority of the models focus on the dangers of automated malware (i.e., viruses, worms, Trojans, and bots), which previously were not given enough attention and have plagued the earlier versions of Windows.

Note

You can read more about SDL at http://www.msdn.microsoft.com/msdnmag/issues/05/11/SDL/default.aspx.

Most, if not all, Windows Vista developers have been trained in secure coding and SDL. All code is examined through several cycles of manual and automated review. Programmers review their own code and then submit it to peers for further analysis. Coders from one team review the code of other teams, and then hand it off to external code review teams.

Automated code review tools and fuzzers (http://www.en.wikipedia.org/wiki/Fuzz_testing) are used to spot previously missed code flaws. Microsoft is also expanding the use of meta-language, called Standard Annotation Language (SAL), which helps static analysis (i.e., code review) tools find more bugs with a bit more upfront annotation and documentation by the developer. See Michael Howard's blog (http://www.blogs.msdn.com/micheal_howard/archive/2006/05/19/602077.aspx) for more details.

Microsoft's Secure Windows Initiative Attack Team (SWIAT), their in-house red-team, along with external penetration testers, try to exploit what comes out of the multiple code reviews. Any found flaws are re-submitted back into the SDL process and re-tested. David LeBlanc, Senior Microsoft Software Development Engineer, has stated that the SDL process has made the number of bugs per thousands of lines of code (known as bugs/kloc) among the lowest in the industry (http://www.infoworld.com/article/05/09/16/38OPsecadvise_1.html).


Improved C++ Security

Even the software used to write Windows Vista has an increased focus on security. Most of Windows Vista is written in C++ and built with a version of the compiler in the Microsoft Software Developer Kit (SDK). Visual C++, a component of Visual Studio 2005, contains many of these same security enhancements, increasing the number of security protections available to developers. All Windows code is compiled with the /GS switch by default, which prevents many stack-based buffer overflows from being successful. It inserts a sacrificial canary value into the execution space (before the return address of the function entry, if you want the technical details) and in some other strategic places. Using the /GS flag to protect more than the return function is a new feature in the compiler used for Windows Vista and in Visual C++ 2005. Many types of buffer overflows, by their very nature, cannot avoid overwriting the canary value, which allows Windows to detect the error condition and halt the affected program.

Significantly more effort is focused on preventing attackers from using legitimate code against itself. Programming functions particularly prone to problems, such as strcpy, strncpy, and so on, have been deprecated and all code in Windows Vista was required to replace them with less vulnerable substitutes. You can find a complete list of banned functions and APIs, and their replacements at http://www.msdn2.microsoft.com/en-us/library/bb288454.aspx.

Malware will often purposefully trigger exceptions and flow the program execution into a malicious exception handling routine. All Windows code has been compiled with the Safe Exception Handling switch (/SafeSEH), which hard codes approved exception addresses into the compiled Windows executable header.


Address Space Layout Randomization

One of the most talked about new programming features is Address Space Layout Randomization (or ASLR). In previous versions of Windows, common Windows APIs (located in Kernel32.dll, Gdi32.dll, Wsock32.dll, and so on) were loaded into well-known or easily discoverable locations. In XP and previous versions of Windows, these APIs were always placed in the same memory location. Malicious code could locate a needed API directly in memory, bypassing OS security mechanisms. ASLR randomly places common Windows APIs in one of 256 possible places during each boot up. With Vista, a malware program trying to directly access the Windows API must guess, on its first try, the correct memory location. Statistically, the program will only correctly guess 1 in every 256 tries. This single feature defeats thousands of old legacy attack programs and makes newer malware programs work less reliably.

Microsoft doesn't stop there. Function memory address pointers are obscured, heap memory blocks are obscured and checksummed, various heap memory metadata elements are XOR-encoded with a random number, and heap memory base addresses are randomized. If Windows Vista detects a problem the application is terminated and recovery is started.

Note

Many of Windows Vista's new security features have been discovered outside of Microsoft. Various BSD and Linux distributions have had a feature similar to ASLR for several years. While some critics blast Microsoft for appropriating open source ideas, most security analysts applaud Microsoft for adopting, and in some cases improving upon, industry-tested solutions.


Data Execution Protection

Buffer overflows work by unexpectedly co-mingling data and executable code in a single memory area. The buffer overflow places executable code into a section of memory that is then executed by the processor.

Data Execution Protection (DEP), which was introduced in Windows XP Pro SP2, and is improved in Windows Vista, can be used to prevent co-mingled data from being maliciously executed. DEP can be enabled in software, or on No eXecute (NX) processor chips, in hardware. These chips, available both from AMD and Intel, contain a hardware-based security feature that allows pages of memory to be marked as non-executable. NX-capable processors (called XD by AMD) must be accompanied by an NX-capable BIOS and mother board, and further supported by an NX-capable OS (such as Windows Vista) and applications.

By default, Windows XP Pro and later (including Windows Server 2003 SP1) system files are protected by DEP, and by NX chips if present. Software developers can also configure their applications to use DEP or NX. Administrators can use the Advanced Settings option under the System control panel applet, and then Advanced and Performance options to customize which programs to be protected (see Figure 1-1). However, many programs will refuse to run or will have operational problems if DEP or NX is enabled, so ensure application compatibility first before enabling for additional files beyond the Windows defaults.

Image from book
Figure 1-1: DEP can be enabled for all processes that are not specifically exempted.
Note

NX-enabled software is also available in other operating systems, such as Linux and BSD. See http://www.en.wikipedia.org/wiki/NX_bit for more details.


Protected Processes

In prior versions of Windows, parent processes have complete control over their child processes, and administratively started processes can control other processes. A common malware ploy is to maliciously manipulate an existing legitimate application or service into running a new malicious process. Often the new malicious process will incorrectly appear to the operating system and other defense tools as a legitimate child process. Or a rogue invoked process can modify another completely unrelated legitimate process into doing something malicious.

Windows Vista introduces the concept of protected processes (unfortunately currently focused on DRM technologies and content), which run alongside non-protected processes. Only system and application files digitally signed and belonging to the Windows Protected Media Path (WMPM) can create a protected process. When a process is protected, a non-protected process or thread cannot:

  • Access the virtual memory area of a protected process

  • Debug an active protected process

  • Inject a new thread into a protected process

  • Impersonate a thread

  • Set or receive context information

  • Duplicate a handle from a protected process

There are other process protections, as you can read about at http://www.microsoft.com/whdc/system/Vista/process_Vista.mspx.

Note

Protected processes can be recognized in the Task Manager by locating processes (besides System and System Idle) with no values present in the Data Execution Prevention or Virtualization columns. Enable Show processes from all users and add the Data Execution Prevention and Virtualization columns to the list of columns displayed on Task Manager's Processes view. You can run Vista's Audiodg.exe program as an example. Protected processes appear in Task Manager.


Windows Vista User Experience

In what Microsoft calls the Windows Vista User Experience (UX), it is promoting easier-to-understand, friendlier messages throughout Windows Vista-in the event logs, error messages, and dialog boxes. There is also added detail in most instances, which will appeal to administrators. For example, many of the security User Interfaces (UI) showing a program filename will display the full folder path location to the executable. For security administrators, this makes it easier to track down and identify programs.

Although there are ways to defeat all of the new security programming mechanisms, it makes the job considerably more difficult for malware writers. This, in fact, was all Microsoft intended. One thing that is refreshing is that the core security team, at least, never lost sight of the reality that nothing is foolproof.


Host-Based Security

Most of the new security changes directly affect the Windows Vista computer-the host. This section starts with the boot and startup changes, and then discusses the operational aspects.

Boot Changes

There are major differences in the Windows Vista boot sequence, including the Boot Configuration Data store, new boot files, new system recovery tools, and BitLocker Drive Encryption technology.

Boot Configuration Data

In most of today's PC-based systems, the BIOS is responsible for locating the primary boot drive, which loads the system partition, which then loads the operating system.

A newer emerging boot process open standard called Extensible Firmware Interface (EFI) will work on EFI-enabled computing devices. EFI is a more flexible framework for bridging the boot-up gap between hardware and software, storing EFI-related variables in non-volatile RAM. EFI will allow operating systems to move more transparently beyond traditional desktop and laptop computer form factors (for example, to PDAs, cell phones, wearable computers, and so on). EFI-enabled operating systems require more hierarchal complexity than a simple text file can provide.

The Boot Configuration Data (BCD) store replaces the Boot.ini file used in previous versions of Windows. If Windows Vista is the only OS installed on a boot volume, the boot.ini file will not be created or used. However, the boot.ini file is still supported for legacy dual-booting scenarios on computers with an AT/BIOS chip.

The BCD store and its associated editor, Bcdedit.exe, are intended to interface Windows Vista and later operating systems with EFI. Unfortunately, the complete EFI standard emerged too late to be included in 32-bit versions of Windows Vista. EFI support is available in 64-bit versions of Windows Vista and Longhorn.

Windows Vista's boot process now includes the following new files (among others):

  • Bootmgr, a hidden file located in the root directory of the boot volume, controls boot flow and multi-boot options on a dual-or multi-boot situation

  • The BCD store is a (non-hidden) hierarchical binary file stored in the hidden \boot folder. Microsoft describes it as a registry hive file, but it is not supposed to be accessed using normal registry tools. On EFI-enabled computers, BCD will be stored under \EFI\Microsoft\Boot on the EFI system partition.

  • Located in the hidden \boot folder is also a hidden 64K Bootstat.dat file created at install, and one or more hidden BCD log files named BCD.log, BCD.LOG1, BCD.LOG2, and so on, which can be used for diagnostic purposes.

  • Winload.exe (located in \Windows\System32) is the new OS loader, replacing NTLDR. It loads the kernel files, HAL, and boot device drivers into memory.

Firmware-independent BCD can work with PC AT/BIOS or EFI-enabled computers and is designed to handle multiple versions of Windows and even non-Windows operating systems. If a legacy (i.e., prior to Windows Vista) version of Windows is installed on a separate partition on the same computer as Windows Vista, the legacy Windows program will still use its own NTLDR and boot.ini files.

The BCD store should be managed using the new command-line program, Bcdedit.exe located in \Windows\System32 or with the BCD WMI provider. Administrative privileges are required to view and modify BCD settings using Bcdedit.exe. You can type in Bcdedit.exe /enum to see current settings or Bcdedit.exe /export to export current settings. Type in Bcdedit.exe /? topics to get a full list of commands and syntax.

Note

To get an administrative command prompt, all you need to do is right-click on a shortcut to the command prompt and select "Run as administrator …". See Chapter 4 for more details on User Account Control (UAC).

The System control panel applet still interfaces with the global boot settings that allow administrators to pick the boot order and boot manager timeout setting. Msconfig.exe interfaces with the BCD store as well. As was possible with the Boot.ini and Bootcfg.exe files in previous versions, a troubleshooter can set special diagnostic parameters or EMS parameters, or enable kernel debugging using Bcdedit.exe. Bootcfg.exe is included with Windows Vista, but cannot modify the BCD store. It can be used only to view and modify legacy Boot.ini files on dual-boot systems. Bcdedit.exe can also be used to modify earlier versions of Windows.

Note

Winresume.exe is located in \Windows\System32 and helps Windows Vista resume from hibernation along with the hidden Hiberfil.sys file in the root directory that would hold the saved memory contents.

You can read more about BCD and EFI at http://www.microsoft.com/whdc/system/platform/firmware/bcd.mspx.

System Recovery

Windows Vista includes major improvements to Microsoft system recovery tools, including the Windows Pre-Installation Environment (WinPE), Windows Recovery Environment (WinRE), and the Startup Recovery Tool (SRT).

WinPE essentially replaces the DOS boot diskettes and/or Recovery Console needed in previous versions of Windows. It loads a mini-version of the Windows Vista OS, and can be used for deployment scenarios, troubleshooting, and system recovery.

WinPE is loaded from the large \sources\boot.wim (Windows Imaging) file located on the original installation media during Windows Vista's initial install, but can be loaded from any bootable media, including a USB Flash Memory drive. (See Appendix A for directions on how to build a USB Memory Stick with WinPE.) During installation of Windows Vista, WinPE boots to the first GUI the user sees. During this time a user can press Shift+F10 to exit the displayed GUI to a WinPE command prompt.

WinPE runs completely in memory (requires 256MB memory), and has the following features:

  • Provides full access to FAT and NTFS file systems (for file copying, data recovery, and so on)

  • Creates and formats disk partitions

  • Driver injection, where critical drivers can be loaded before WinPE boots fully

  • Detects and enables most hardware devices, and supports 32-bit and 64-bit device drivers

  • Enables TCP/IP networking support

  • Runs a robust Win32 API, which supports most 32-bit applications, scripts, batch files, ActiveX, and HTML applications

  • Text-based console, WinRE, with several built-in diagnostic tools and commands (including Diskpart, Drvload, Net, and Netcfg)

WinPE was previously available to XP environments with Software Assurance agreements, but in Windows Vista everyone gets an improved version known as WinPE 2.0.

Startup Repair Tool

If Windows Vista fails to boot up and load properly, WinPE (often loaded on an OEM hard drive partition) will automatically load WinRE and the Startup Repair Tool (SRT). Microsoft did a lot of research on bootup system failures and their causes. SRT analyzes the startup logs looking for the problem. The SRT and its Setup Repair Wizard can fix upwards of 80 percent of all known failures (according to Microsoft).

If the failure cannot be automatically repaired, the SRT will attempt to roll back the system into a previously known good state. Only time will tell if the new rollback is better than it was in previous versions. If the rollback does not repair the problem, the SRT will provide detailed diagnostic information and offers additional support options.

Administrators can use WinPE, WinRE, and the SRT to diagnose and repair damage, malicious and otherwise. Because WinPE allows 32-bit applications to be run and recognizes NTFS partitions, it is possible to run fully functional antivirus and malware removal tools. Access to NTFS partitions assumes the user has appropriate administrative permissions, of course, and that the boot drive is not encrypted.

BitLocker Drive Encryption and TPM

In previous versions of Windows, malicious attackers have been successful in booting around the operating system protections provided by Microsoft. If the attacker can boot up on another operating system (for example, Linux, Knoppix, and so on) that can read NTFS partitions, the attacker can copy data and password hashes from the exploited system.

To prevent physical "boot-around" attacks, the Enterprise and Ultimate versions of Windows Vista have the ability to encrypt the entire OS boot volume using a new feature called BitLocker Drive Encryption. When enabled, the primary boot volume remains encrypted until decryption keys are supplied. The key can be stored in a Trust Platform Module (TPM) chip located on the mother board or on a USB key (and, for backup purposes, a recovery key can stored in Active Directory as well if the domain controllers have been upgraded with the appropriate schema).

A TPM chip is a specialized cryptographic chip located on the motherboard or added on via an interface card, with a supporting TPM-enabled mother-board and Trusted Computing Group-(TCG-) compliant BIOS. Among many other possible functions, a TPM chip can securely protect the BitLocker decryption key. The TPM can be configured to automatically decrypt the Bit-Locker volume decryption key when Windows boots (and is in control of security), or to require a PIN to be entered by a local user, or read from a USB flash memory drive, or a combination of all three. If a TPM chip is used, it will also verify that the hardware has not been tampered with. This is why it is crucial to turn off BitLocker before upgrading the BIOS on your computer. Otherwise the TPM will detect that the hardware has been tampered with and will lock the system and require a recovery key to boot it.

In order for BitLocker to work, the participating primary boot drive must have two NTFS partitions. The first is for the unencrypted boot information, and the second holds the encrypted partition. There is a new Control Panel applet to enable, configure, and disable BitLocker. BitLocker will be covered in more detail in Chapter 3.

Note

Windows Vista contains a new MMC console, Tpm.msc, for administrating and initializing TPM, which must be enabled before turning on BitLocker, if you wish to use the TPM to store BitLocker keys.

Security Defaults

Windows Vista has considerably stronger default security settings than Windows XP Pro, particularly the early versions. Here are some of the default settings:

  • Administrator account is often disabled, but can be enabled.

  • User Account Control is enabled.

  • Internet Explorer is in Protected Mode (covered below) for all security zones except the Trusted sites zone.

  • Most inbound connections are blocked by Windows Firewall (most outbound connections are allowed by default, but many programs and services are blocked from communicating out).

  • Automatic Updates is enabled.

  • Windows Security Center is activated.

  • Windows Defender (and SpyNet) is enabled by default.

  • A password-protected screensaver is enabled by default.

These settings make Windows Vista relatively secure out-of-the-box. The Windows Security Center display will appear reporting on the current status of most of the items in the preceding list and allow you to make adjustments, if needed.

Windows Defender

Windows Vista actively uses Microsoft Windows Defender (see Figure 1-2), which was previously released as an extended beta trial for XP SP2 users. Bought originally from Giant Software, Windows Defender is an excellent spyware prevention and removal program. It allows scheduled scans and real-time protection. When enabled, the real-time protection monitors the registry, auto-start locations, services, and Internet Explorer for spyware-like activity. In independent tests with other competitors, it always ranks near the top in accuracy.

Image from book
Figure 1-2: Windows Defender is included in Windows Vista.

By default, users are joined to Microsoft's SpyNet online community. SpyNet membership instructs Windows Defender to send each user's personal decision on what to do with newly identified potential spyware (i.e., allow or remove) to the SpyNet database. Collected responses are used to identify new spyware, which then updates the Windows Defender definitions. Windows Defender is covered in more detail in Chapter 7.

Malicious Software Removal Tool

The Microsoft Malicious Software Removal Tool is executed by default during new installs and when the system is updated with Microsoft Update. Originally written for Windows XP SP2, the Malicious Software Removal Tool checks for and removes only the most popular malware at the time of its download. It does not check for all malware as a more general anti-malware program might.

Microsoft created the tool in response to failed installations of its updates due to malware. Many of the failed installations could be traced to customers having actively compromised and exploited computers. The installed malware programs would prevent Microsoft's new software from being installed, which the users then blamed on Microsoft.

Microsoft uses both Windows Defender and the Malicious Software Removal Tool to gauge how popular a particular malware program is. This, in turn, helps guide its response. Some very critical dangerous zero-day threats have been measured as infecting only a handful out of 25 million users. When the spread of a threat is small, as in the previous example, Microsoft waits to release the defense patch until the normal monthly "Patch Tuesday" cycle. If the malware is spreading quickly and is a critical threat, Microsoft will often release the offsetting patch "out-of-band" before the normal release date.

Improved Logon Architecture

Windows Vista strengthens existing password authentication and has improved support for smart cards, fingerprint scanners, biometrics, and so on.

LAN Manager Disabled

First, LAN Manager (LM) password hashes are disabled by default. Disabling LM password hashes is the single best step to prevent Windows password cracking (i.e., hash to plain-text conversions) that Microsoft could have made. The option to disable LM hashes was available in past Windows versions, but was disabled by default, so most administrators never did it.

Windows Vista also disables outbound LM and NTLM version 1 authentication protocols, leaving only NTLM version 2 and Kerberos enabled by default (although all four authentication protocols are still accepted inbound for backward compatibility with connecting clients without increasing malicious risk). This step helps prevent password cracking from network eavesdropping programs (Cain, for example). Both decisions are long overdue and have very solid security goals, but may cause problems in some environments with legacy Windows computers and applications.

Better Support for Additional Authentication Methods

Microsoft has also made it easier to integrate non-password authentication methods, and even multiple, simultaneous authentication methods, in the logon process. Since Windows 2000 you can use smart cards for authentication, and more recently, you can replace the logon interface with one from third-party providers to log on with RSA SecurID tokens, for example. However, you can use only one authentication method at a time. Windows Vista has a completely new Winlogon architecture and a new Credential Providers API that gives improved built-in support for smart cards, USB tokens, two-factor authentication, and more, and allows for multiple credentials to be used at the same time.

In past versions of Windows, end users interacted with the Microsoft Graphical Interface for Network Authentication (GINA), implemented in Msgina.dll, to logon. Winlogon.exe handled the logon process, but the Microsoft GINA displayed the logon dialog box where the user typed in their user account name and password (and any other necessary information such as target domain name). When administrators wanted to add another form of authentication, it required (in most cases) that the Microsoft GINA be replaced by another vendor's GINA. For instance, if biometrics were implemented, the Microsoft GINA would be replaced by the biometrics vendor's GINA, so it could prompt users for a copy of their fingerprints, instead of a password.

Unfortunately, when a vendor replaced the original GINA, the vendor's software was now in total control of the user's logon security. Replacing the original GINA often caused problems or prevented the use of other Windows features (for example, Terminal Services, Remote Desktop, and so on) and broke many other applications. To make matters worse, many vendors poorly coded their replacement GINAs so it weakened overall security. Microsoft, having not written the GINA, could not patch it, and getting vendor patches often proved complicated.

In Windows Vista, a new Credential Providers API replaces the legacy GINA and all user logons are accomplished through a new user logon interface (Logonui.exe). Vendors must write their authentication interfaces and programs to interface with the new Credential Providers API (see Figure 1-3 for an old versus new comparison). The Credential Providers API interfaces with the logon user interface (called LogonUI), and the LogonUI can handle multiple vendor implementations at once. Vendors use COM programming to ask the LogonUI to gather the necessary data on their behalf. More on this in Chapter 3.

Image from book
Figure 1-3: The new Windows logon process provides more granular hooks for enhancement.

Windows Vista ships with built-in password and smart card credential providers, but Microsoft is working heavily to influence other credential providers into using the new API.

Session Isolation

Another huge improvement has been made to logon session security. Multiple user sessions can be started in Windows at one time. One session is always started when Windows starts and the services are loaded. Another session is started when the first user logs on. Additional sessions can be started (for example, using RunAs, Remote Desktop, Terminal Services, Fast User Switching, and so on). The first session is numbered Session 0, and additional sessions are given incremented numbers (for example, Session 1, Session 2, and so on). Unbeknownst to most users, many applications (for example, antivirus software) actually run in additional sessions.

In previous versions of Windows, all the programs started by the first user ran in Session 0, along with the already started services and other kernel mode processes. Additional sessions could be started, but could easily interact and communicate with the other sessions. This allowed applications and services in one session to talk to users and software in other sessions. For example, the background running antivirus scan (running in a different session) could send a message (for example, "Virus found!") to the user computing in Session 0.

Unfortunately, there are two weaknesses to this method. First, having a regular user whose interactive desktop is in the same session as system services presents an obvious security problem. Second, allowing additional sessions to communicate with and interact with the first session (i.e., Session 0) opens up other potential vulnerabilities. Attackers used a class of attacks called "shatter" vulnerabilities to exploit more privileged sessions using less privileged sessions (i.e., privileged escalation).

In Windows Vista, Session 0 is reserved for Windows kernel code and system services. Users never interact with Session 0 directly, and other sessions cannot communicate directly to Session 0. This prevents many different types of attacks, including the whole class of shatter attacks. Unfortunately, this also means that any application that installs itself as a service will no longer be able to directly interact with Windows system services (for example, graphics driver, and so on) or with the end user (which is often the done by many poorly written services). Service applications will have to be re-written to work correctly or interface with the end user for Windows Vista.

A new service called the Interactive Service Detection Service is available to help bridge legacy service applications until they can be re-written. When the new service detects a legacy application trying to send a message to the interactive user, the message will be intercepted, and the user prompted to accept the incoming communication from the application. Although getting the approval of a user before being able to accept a dialog box from an application may appear draconian, session isolation is a much needed improvement for Windows security. Without it, Windows would continue to be very vulnerable to local privilege escalation attacks.

Service Hardening

Microsoft has done more than separate the services from the user and application sessions. It has also made every default installed Windows service follow a least privileged security model. Each service was reviewed, and unnecessary permissions were removed. On the book's Web site you will find a complete list of services in Windows Vista, along with their associated security settings.

Windows XP introduced the lower privileged service accounts of Local Service and Network Service, which replaced Local System when possible. Windows Vista continues this trend, and percentage-wise, more services use non-Local System security contexts than any of the previous Windows operating systems. Windows Vista introduces even more service security.

Every service is assigned a SID, which is something the previous operating systems did not do. This allows the service to be tracked uniquely, and makes it easier to assign permissions. The Service Control Manager (SCM) reviews the privileges a service needs during start up and removes unnecessary privileges.

Once started, the service cannot be given new or additional privileges. The SCM adds many services to the Restricted SID to further restrict what a service can do. By default, a service can only write to an object that specifically allows services to write to it. For example, the Remote Procedure Call service cannot replace system files, modify the registry, or modify other system services or applications (for example, antivirus scanning protection). This change alone would have prevented the Blaster worm outbreak a few years ago. (SIDs are discussed more in Chapter 5.)

Services are now allowed to have failure actions even when the service doesn't become fully inoperable. In past operating systems, failure actions could be defined only when the service stopped responding and crashed completely. Now, high CPU utilization loads, memory leaks, and so on can trigger recovery actions.

On a slightly related note, services can now avail themselves of a new Automatic startup type called delayed start. Delayed start services don't immediately start when the system boots, but instead wait a short period of time, and even then start with low priority.

Services are also assigned a default network firewall policy and connection scope. It makes it harder for a local service to initiate outbound connections attacking other non-local networks. Many of the previously successful buffer overflow attacks worked by overrunning a service and then using the infected host to attack remote networks. This change would have significantly lessened the impact of the Blaster and SQL.Slammer worms. Microsoft is working with vendors to help them follow the new service hardening methodologies. Services that don't may not work in Windows Vista. This is discussed more in Chapter 11.

Enhanced Device Driver Experience

All Microsoft device drivers are extensively tested for security, reliability, and digitally signed by default. All critical system drivers must be signed to be loaded into the kernel smoothly. On 32-bit systems, unsigned drivers will send a warning to administrators, but can still be loaded. On 64-bit systems, unsigned drivers cannot be loaded-period. Windows Vista even ships with a list of device drivers known to cause problems and not allow them to load.

The Windows Vista Device Driver Experience allows administrators to sign their own drivers and have the ability to restrict what devices and device drivers can be installed in their own environments. Administrators can even place a device driver on a network share and point managed computers to automatically install it.

User-Mode Driver Framework

According to Microsoft and Mark Russinovich, 99 percent of "blue screens" are caused by incorrectly written third-party device drivers. Windows Vista's new User-Mode Driver Framework (UMDF) is a new device driver methodology that attempts to prevent operating system crashes. With UMDF, a UMDF service running in the Local Service (not Local System) security context hosts all UMDF device drivers. UMDF drivers cannot directly access kernel mode code, memory, or hardware. Developers using the new UMDF host driver can be assured that their software additions will not compromise Vista's kernel causing critical operational errors.

Portable Media Device Control

Whether users can use portable media devices, such as USB flash memory drives, CD-ROMs, DVDs, and so on, can now be controlled. Administrators can decide whether to allow read-only or read and write access to the portable media, on a per machine or per user basis. Of course, settings can be controlled using group policy. This enables administrators to make theft of confidential data more inconvenient and makes injecting malicious code accidentally harder. The Device Manager applet contains a new Auto-play applet, which allows administrators to choose which media devices will allow auto-play or not.

ReadyBoost Memory

Windows Vista's ReadyBoost technology will also allow USB flash memory drives (256MB–4GB) and other memory cards (for example, SD memory, Compact Flash, and so on) to be used for additional page file virtual memory to increase Windows performance when more memory is needed. It's restricted to one device per computer, and the USB device must support USB 2.0 and fast memory transfers. All paging file data stored on the USB device is first stored on the local hard drive, and then cached to the USB device. All data stored on the USB flash memory device is automatically encrypted using 128-bit AES. When the device is unplugged, Windows Vista immediately drops back to using the local drive cache.

User Account Control

User Account Control (UAC) is certainly the most talked about security improvement to Windows Vista, and has the most end-user experience impact. Called User Account Protection during early development, UAC was created to minimize the risk of a user being logged in as an administrator when not conducting administrative business (e.g. browsing the Web, picking up e-mail, etc.). If regular end users and administrators were not logged in as members of the Administrators group all the time, the majority of all popular malware and hacker attacks would not work. Not running as an Administrator constantly is one of the most significant security improvement steps any Windows user can take.

However, if an end user isn't an administrator, it means she cannot install new applications, or easily manage her own environment. Previous versions of Windows could be very unfriendly for users without admin privileges. For example, non-admin users could not:

  • Change their system time or time zone

  • Change power management settings

  • Change the default programs

  • Install Internet Explorer add-ons or change security settings

  • Create a share

  • Add a printer

  • Add a new device

With the exception of modifying personal profile and desktop settings, a non-admin user can't modify Windows much at all. And that is the intent. A non-admin user shouldn't be able to do anything that would affect the security of Windows. Unfortunately, most organizations would find their end users rioting if the end users could not install their own programs, drivers, and change system configuration settings.

The net effect of the way that previous versions of Windows handled admin versus non-admin users was that most companies made all their end users members of the local Administrators group. Microsoft didn't make matters better by making all newly created user accounts automatically members of the Administrators group by default on non-domain computers.

Windows Vista and UAC to the rescue! UAC ensures that even if a user is logged on with an admin-level account all the time, that they don't have administrator-level privileges enabled all the time. UAC works by assigning all admin users two security access tokens-one non-admin used most of the time and one admin only used when needed. UAC only enables Administrator privileges when needed and only on additional approval by the user. For more details on UAC, see Chapter 4.

Secure Desktop

Microsoft has gone to great effort to secure the desktop environment against malicious code and malware. Prior versions of Windows also had what is called the Secure Desktop. The Secure Desktop is where logon dialog boxes, password change dialog boxes, and so on show up. In Windows Vista, that is also where UAC dialog boxes show up by default. This prevents them from being dismissed by malware on the user's desktop.

When UAC dims the rest of the screen while you answer a UAC or application message you are actually seeing the Secure Desktop (see Figure 1-4). The OS actually takes a screenshot of your desktop, puts a gray mask over it, and displays that as the background behind the UAC dialog box. So, even if the user was able to move their mouse cursor or keyboard focus off the correct foreground object, there would be nothing to click on or to respond to. The background is an image with no real controls or objects. It's a brilliant idea that prevents many attack types. This will be discussed in Chapter 4.

Image from book
Figure 1-4: The UAC elevation dialog box is on the secure desktop.

Mandatory Integrity Control

All security principals (user, computer, service, and so on), or processes acting on behalf of a security principal, and resources are now assigned an integrity SID in their access token. This is another huge improvement to Windows security, and is the keystone technology that allows Microsoft to implement UAC, Internet Explorer-Protected Mode, and many other significant advances. Understanding this new feature is critical for Windows administrators and security managers.

In all NT-class versions of Windows (i.e., NT, XP, Server 2003, Windows Vista, and so on), after a security principal logs on and is successfully authenticated, it is assigned an access token. The access token holds (among many items) the security principal's individual security identifier (SID), the SIDs of the groups they belong to, and assigned user rights. When a security principal or a process on behalf of a security principal attempts to access an object, the security principal's access token is handed over for inspection by the Windows security manager process (Lsass.exe). The access token essentially says, "This is who I am and the groups I belong to, and the rights I have." The Windows security manager compares to the access token to the object's access control list (ACL) to determine effective permissions. It's the way NTFS permissions work in Windows and it is covered in detail in Chapter 5.

Windows Vista adds a new integrity SID to the access token. Its value can indicate low, medium, high, or system integrity. All Windows objects (for example, files, printers, registry keys, and so on) are also assigned default integrity values. System objects are given the highest integrity rating of system. Most users and applications are given medium integrity by default. All normal Windows files and the desktop have medium integrity, but Internet Explorer running in Protected Mode, and all of its add-ons, toolbars, etc., run with low integrity.

When a security principal (or process) attempts to access an object, the security principal's and object's integrity SIDs are checked first. If the security principal's integrity rating is equal to or greater than the object's integrity value, then it is still possible for the security principal to write, modify, or delete the object, if the subsequent NTFS security permissions also allow it. If the security principal's integrity level is lower, the security principal will not be able to write, modify, or delete the object they are attempting to access regardless of their NTFS permissions. Integrity SIDs have precedence over NTFS permissions. This is an incredibly important feature.

The idea is that even if a malicious program is able to "break out" into a system, if it originates from a low or medium integrity process, it will have a hard time modifying the system files of Windows, as they are protected not only by an access control list, but also by the system integrity label. For example, Internet Explorer in Protected mode runs with low integrity. If malware exploits

Internet Explorer and then attempts to leverage that exploit into further compromising the system, the new integrity controls will make it much more difficult to accomplish.

This is yet again another security mechanism that will help prevent malware and hackers from modifying local system resources, especially if those attacks originate using Internet Explorer or on the user's desktop.

Improved File, Folder, and Registry Protection

Microsoft has invested significantly in preventing unauthorized access to files, folders, and registry keys located on Windows Vista. Many folders and files have moved or no longer exist. For instance, the \Documents and Settings folder where profiles and user documents are stored has become \Users. The All Users profile, which is applied for all logon users, has been moved out of the normal profile file (now \Users) and moved to %userprofiles%\public in the root directory, to simplify security on the individual user profiles.

Several potentially dangerous \Windows\System32 files, which all users could execute, have been removed, such as: tftp.exe, tlntsvr.exe, clpsrv.exe, ntbackup.exe, tsshutdn.exe, auditusr.exe, ddeshare.exe, rcp.exe, rexec.exe, rsh.exe, rsm.exe, and telnet.exe. Although why regular end users still have access to debug.exe, edlin.exe, and tskill.exe, still makes you wonder. There are plenty of new files in \Windows\System32, such as Atbroker.exe, Bcdedit.exe, and Bridgeunattend.exe available for users and hackers to explore.

NTFS Changes

Microsoft made several changes to NTFS (Windows NT file system), although most are continuations or improvements from previous Windows versions. NTFS is now more reliable. File or registry keys written to by Transactional NTFS (TxF)-aware applications can be rolled back if the write operation is incomplete for any reason. Making sure a transaction is complete before it is committed permanently is known as atomicity. Databases and Active Directory have had this for a long time; it's just new to NTFS files and registry keys.

NTFS now allows end users to create symbolic links. A symbolic link is a shortcut placeholder that, if chosen, will take the end user or program to another location or resource. NTFS has supported junction points (similar to symbolic links) for directories, but only if they were made programmatically, and even then only barely supported. However, junction points could only refer to local resources, whereas symbolic links can even point to remote resources. Windows Vista allows end users to make, manage, or delete symbolic links on files or folders using the new Mlink.exe utility. And symbolic links will show up in DOS directory listings (dir /ah) with a <JUNCTION> descriptor attached. In Windows Explorer, symbolic links show up with a modified folder icon (arrow jutting out from the left side).

Windows Vista now supports Previous Version file and folder restores on local files as well as network-based files. By default, the Volume Shadow Copy service is running and protecting files and folders on the system volume. The System Restore feature of Windows Vista regularly makes Restore Points before important events (for example, big installs, bootups, prior to patch updates, and so on), periodically if no big events happen, and can be made manually at any time (using the System Protection tab under the System applet).

Prior versions of System Restore Points made a backup of only Windows system files, but now it captures file and folder changes made under the \Users folder as well. If an end user accidentally makes a file or folder modification they did not intend, they can right-click the file or folder (or parent folder if they deleted the file or folder) and restore a previous version.

Creator Owners Can Be Prevented from Having Full Control

Object creators can now be prevented from automatically having Full Control over an object that they created. Windows Vista has a feature called Owner Access Restriction (OAR), which allows Administrators to define the default permissions given to a Creator Owner for a given resource or location. To do this, Microsoft had to add a Creator Owner access control entry (ACE) as an available security permission that can be modified and controlled. This new feature will also be covered in Chapter 5.

Per Socket Permissions

Access control list permissions on a resource can be controlled on a per socket (http://www.en.wikipedia.org/wiki/Internet_socket) basis. Discretionary ACLs (security permissions) were available on a per socket basis starting with Windows Server 2003 SP1. Windows Vista allows System ACLS (SACLs) to be set on a per socket basis as well. Although non-programmers won't understand the security significance, it essentially allows programmers to prevent unauthorized applications and security principals from binding to an unauthorized socket. The overall effect can prevent some forms of malware from easily working. For more information on controlling access to sockets, see Chapter 11.

New Built-in Users and Groups

Several new built-in groups have been added to Windows Vista, including:

  • Cryptographic Operators

  • IIS_IUSRS

  • Event Log Readers

Other groups, like IIS_WPG and Power Users, have been deprecated. These group changes will be covered in more detail in Chapter 3.

File and Registry Virtualization

Many programs (and malware) require administrative access to \Windows\ System32, HKLM\Software, and other Windows critical areas to install and run. However, if given that type of access, they can literally modify Windows itself. Malware often does exactly that. The user is tricked into running a malicious program-perhaps by making him believe he is installing some harmless program-but instead, or in addition to that, the malware maliciously modifies Windows to install keylogging Trojans, backdoors, spyware, and identity theft mechanisms.

Windows Vista uses virtualization technology to permit legacy programs to run even though they do not have permissions to modify critical folder and registry areas. If a low or medium integrity program (by default most legacy programs are given medium integrity and Internet Explorer in Protected Mode is low) attempts to write to the most popular Windows critical areas, Windows Vista will redirect the writes (and reads) to a virtualized, per-user, copy of the file system and registry. So, although it appears to the low or medium integrity program as if they are accessing the normal folder and registry areas, they really are being redirected to a low integrity resource where it can do less overall harm. Virtualization can be enabled or disabled via group policy. By default, the following locations will be redirected to virtualized areas:

  • \Program Files

  • \Windows

  • \Windows\System32

  • \Documents and Settings

  • HKLM\Software

Overall, Windows Vista's integrity controls and virtualization technology will further complicate malware exploitation. See Chapter 4 for a lot more detail on these features.

Windows Resource Protection

Since Windows ME and Windows 2000, the majority of Windows system files have been protected from deletion and unauthorized modification. In ME, the protection was called System File Protection. In Windows 2000 and later, it is known as Windows File Protection (WFP). For example, if a user deleted the Wscript.exe file in the \Windows\System32 folder, it would "magically" re-appear a few seconds later. If a virus modified Kernel32.dll, the modified version would be replaced with an original, unmodified copy.

Although WFP was not created with the intent to defeat computer viruses, that's essentially what happened. If a computer virus modified any protected Windows file, Windows removed the infection by replacing the modified file with a clean copy. WFP wasn't perfect to be sure, but it did have its value, and did lead to the decrease in number of computer viruses. Computer worms and Trojans became more popular with malware writers because they don't rely on modifying legitimate host files to spread.

In Windows Vista, WFP is now called Windows Resource Protection (WRP). Like WFP, it prevents the replacement of essential system files, folders, and registry keys that are installed as part of Windows Vista. But it does a better job. WFP wasn't prevention. It allowed the protected file to be modified or erased, but quickly responded to replace the modified or deleted file. WRP prevents the modification or deletion in the first place. Even the Administrator or elevated user cannot delete or modify system files. Only the Trusted - Installer Service can do so, subject to integrity controls and NTFS permissions. (Trusted Installer is discussed further in Chapter 5.)

Encryption Enhancements

Windows Vista improves upon Microsoft's previous encryption support. First, Windows Vista includes a Suite B-compliant crypto implementation (http://www.nsa.gov/ia/industry/crypto_suite_b.cfm?MenuID=10.2.7). That means that the latest encryption algorithms are available, including kernel support for Asymmetric Encryption Standard (AES) and Elliptical Curve Cryptography (ECC). With kernel support for the newest algorithms, these algorithms can be used for things that in the past were impossible, such as IPsec. Consequently, the default IPsec configuration is to use AES-128 for encryption and SHA-1 for integrity. Diffie-Hellman Group 2 is used for key-exchange to maintain backward compatibility but organizations with a pure Windows Vista/Windows Code-name Longhorn Server deployment may elect to use several algorithms, including Elliptic Curve Diffie-Hellman, P-384 if processing overhead is no objective and security is paramount.

Microsoft has submitted not only its cryptographic providers, but also the code integrity module, BitLocker, the boot loader, and the OS loader validation against the Federal Information Processing Standard (FIPS) 140-2. Validation may take a year or more, however.

Protocols that had security issues in Windows XP are enhanced in Windows Vista, including Remote Desktop Protocol (RDP), which is used in Remote Desktop, Remote Assistance, and Terminal Services. In Windows XP and Windows 2000, RDP was not authenticated, meaning that it is possible to conduct man-inthe-middle (MitM) attacks against it and its encryption. While Windows Vista supports the legacy versions of RDP, the newer default version requires successful authentication first, before the encryption channels are negotiated.

EFS Enhancements

Encryption File System (EFS) was introduced in Windows 2000 and further improved in Windows XP Pro and Windows Server 2003. Available in the Business, Enterprise, and Ultimate editions of Windows Vista, newer EFS has additional improvements, including:

  • Smart card integration (EFS keys can be stored on smart cards).

  • Offline files are encrypted by user certificates, and not machine certificates as before. This means that if a system is stolen, offline files are actually encrypted with a token that is not present on the system, unlike in Windows XP. This is a significant security improvement in offline files; although the encryption is still only as secure as the user password it is based upon.

  • Several new group policy settings.

  • EFS uses client-side encryption/decryption (so that encrypted data from remote locations is protected when sent across network).

EFS still has plenty of legitimate competition when it comes to protecting confidential data, but for many environments it can provide a sufficient amount of protection without additional software or costs.

RMS-Integrated Client

Windows Rights Management Service (RMS) is a phenomenal product. Using asymmetric authentication and encryption, it allows access to documents and content to be controlled even after the document or content has been distributed. For example, if an employee leaves a company, their access to even existing documents on their hard drive can be removed with a click of the administrative mouse. RMS was released with Windows Server 2003, and XP Pro clients could download an RMS client. Now, an improved version is included by default. Longhorn Server will integrate RMS with Active Directory Federation Services to support cross-company protected collaboration.

Windows Vista will also include improved digital certificate handling and enrollment, and improved backing up and restoring credentials on local computer.

Unix on Windows

Windows Vista Enterprise and Ultimate contain an entire Unix-based environment capable of seamlessly running many Unix and Linux applications. The downloadable utilities even include the ubiquitous gcc compiler. Open source critics have wanted to pan Microsoft's Subsystem for Unix-Based Applications (SUA) from the beginning, but continuous testing has made believers. This means security administrators can run some of their beloved Unix security utilities on Windows Vista, and it also means another (foreign) area to monitor and secure if used by end user applications.

Improved Patch Management

Up-to-date patch management is necessary to secure any OS. Microsoft has included several patch management enhancements to Windows Vista.

Hot Patching and Restart Manager

Again, Microsoft promises fewer reboots. When Windows Vista patches are downloaded, the new Restart Manager examines the patches and determines what software and processes are affected by the update. As long as the patch does not update critical kernel code (for example, Kernel32.dll, Gdi32.dll, and so on), Restart Manager preserves the state of any opened data, stop the process, applies the patch, restarts the process, and restores the open data back to its previous state.

For example, suppose you are working in Microsoft Office when a Microsoft Word patch gets downloaded. Restart Manager asks the user for permission to proceed, saves the state of any current open Microsoft Word documents, closes the document, unloads Microsoft Word, applies the patches, re-starts Microsoft Word, and re-opens the documents into their previous opened state. Imagine, a patch upgrade to Microsoft Office taking only a few seconds, instead of having to close down, reboot the system, and re-open everything else.

Note

Released in Windows Vista, Windows Installer 4.0 supports the Restart Manager and UAC. No backwards compatibility is planned for previous versions of Windows Installer.

Improved Event Logs

It's hard to get excited about Windows event logs, but there are significant, real improvements to impress anyone who has had to sift through Windows event log messages. Event log improvements include:

  • Significantly more event logs all collected in one place

  • Improved messages with more detail

  • Custom views

  • XML formatting

  • Running a task in response to a given event (called event triggers)

  • More granular event logging

  • Event forwarding (collecting events from one or more computers on a single collector computer)

Subscription and Forwarded Events

Microsoft has tried hard to collect more logs into one location. In the past, although the three (or five if you were on a domain controller) generic Windows logs were available in one location, nearly every other application and process had its own logs that were located in a different location.

In Windows Vista, there are dozens of logs by default, each attached to a process, application, or mechanism. For example, there are logs for Internet Explorer, User Account Control, Offline Files, Backup, Setup-related processes, and Group Policy. And vendors can add their logs to the centralized Event Log application.

Note

Sadly, the Windows firewall log does not appear in the Event Viewer or any of its log files.

Each event log message contains more detail and more understandable text (in most cases). Administrators can create customized views (see Figure 1-5) that pull out only particular events that meet a certain criteria. Events can be collected from multiple sources, both local and remote, and seen as one custom view. Custom view configuration files can be exported, sent, and imported to other computers. In addition, the log and the configuration file data are available in XML format for easy integration with databases and event log management systems.

Image from book
Figure 1-5: The new Event Log interface is a vast improvement.

It is important to note that many events have been renumbered in Windows Vista. The rationale is that the events contain more data and a different schema for that data. Most event log management systems are driven by event IDs and changing the schema for existing event IDs would most likely break those event log management systems. Therefore events that have received a modified schema also have a new number.

Any single event log message can be right-clicked and then tied to particular response if it occurs again. By default, an event message can trigger the running of a particular program, sending an e-mail, or displaying a message.

Last, events can be forwarded to other computers or pulled (i.e., subscribed) from other computers. Forwarding and event log subscriptions require that the Windows Remote Management (WinRM) and Windows Event Collector (Wecsvc) services be running.

All-in-all, the Event Viewer application is significantly improved from nearly all angles. Unfortunately, all the improvements will not replace the fact that there are still unrecognizable error messages with little practical detail to help diagnose the real problem. Making sense of it all is not the event log's job, but unfortunately, nobody else seems to have picked up that dropped, and forgotten, gauntlet either.

Note

The Auditpol.exe command will show current audit policy, and replaces the Per-User auditing tool, Auditusr.exe, introduced in Windows XP SP2 and Windows Server 2003 SP1. Auditpol.exe can also be used to configure more granular event logging, such as if you only want to log logon events, but not logoff events. Run auditpol /list /subcategory:* for more details.

Task Manager

Even the security of Task Manager has been improved. Every process and its launching executable can be traced back to the original directory path. This was a feature sorely missing for years. Trojans will now have a more difficult time tricking administrators by hiding as Svchost.exe in C:\Windows\Fonts. You can also click any process and create a dump file, if you are of the hexviewing persuasion.

Increased Emphasis on Backup

A comprehensive security plan always starts and ends with an automated, reliable backup. Microsoft has improved its default backup application. Now named Windows Backup, it can back up the system and/or data to normal backup media (i.e., tape) or to optical disk, USB flash drive, or even to a network share. A complete system image backup can be created using the new CompletePC backup feature. It can be used to quickly restore a completely dead or lost hard drive or computer. A CompletePC restore can be initiated by entering the Windows Recovery Environment (discussed previously) and choosing Windows CompletePC Backup option. And, of course, System Restores and Previous Version restores can also recover user data (if section of the disk where the data is stored is not corrupted) in certain circumstances.


Securing E-mail and the Internet

Outlook Express, Internet Explorer, and Internet Information Server have been improved as well.

Windows Mail

Windows Mail is the new name of Outlook Express. It has been re-written to include intelligent anti-spam and anti-phishing filters. Per the Microsoft development team, the filtering technologies are more sophisticated than the standard Bayesian filters used by most e-mail vendors.

One of the biggest changes from Outlook Express is that each e-mail is stored as a separate .eml file under the \mail folder. Contrast this to the single monolithic file used in the past. Having separate e-mail files means improved performance and improved integration with Windows Explorer. e-mails will be heavily indexed and available in other Explorer content views. Users can also directly access .eml files to reply to a particular e-mail or recipient. Of course, Windows Mail continues Outlook Express's blocking of Active Content in e-mail and opens all e-mail in the Internet Explorer Restricted sites zone. Chapter 10 covers e-mail security.

Internet Explorer

Microsoft has done a fairly good job regarding computer security on nearly every current product with the possible exception of Internet Explorer (IE). With IE running on 95 percent of users' desktops and functionally embedded with every current version of Windows, it gets more attacks than any other Microsoft application. Over the last three years it has announced dozens of vulnerabilities (http://www.secunia.com/product/11). Although competing products are not doing any better. Mozilla Firefox was announced as the browser product that was supposed to be better at security as IE, but in the two years since its release, it has nearly as many vulnerabilities as IE (http://www.secunia.com/product/4227), with a significantly lower market share. Unfortunately, IE is still a prime target and its success or failure is often the only impression most users have of Microsoft computer security.

Microsoft understands this and has invested years of time and dozens of team members in making IE 7.0 as strong a security product as it can. Chapter 8 covers IE 7.0 in detail. Here are some highlights.

First, by default on Windows Vista, it runs in Protected Mode (IE-PM). With IE-PM, IE runs as a low integrity process, and even if the logged on user is an administrator, IE-PM, its add-ons, toolbars, or child processes cannot access higher level integrity resources. Because most applications and resources are medium level integrity it effectively means that IE-PM doesn't have a lot of default access. Even content downloaded from the Internet or Restricted sites zones to the \Temporary Internet Files (TIF) folder is no longer a huge threat. TIF is another virtualized folder marked with low integrity (low integrity files are actually stored in a sub-folder called TIF\Low). IE's History, Cookie, and Favorites files are also marked with low integrity if they were created during a low-integrity browser session. As far as the registry is concerned, IE can access only the low integrity HKCU\Software\Low registry key.

Another huge feature of IE is its new phishing filter. IE has new intelligence to scan incoming web content looking heuristically for signs that might indicate a malicious phishing Web site. By default, IE will also check with Microsoft on every incoming Web site URL to see if it has been previously reported as a malicious Web site. Users can report any Web site to Microsoft as potentially malicious, and Microsoft will verify the site's intent before adding it to its database as malicious.

Other improved IE features are:

  • Parental controls

  • Privacy improvements

  • Pop-up blocking

  • Improved add-on controls

  • Cross domain scripting (XSS) scripting protections

  • URL handling protections

  • Improved digital certificate handling

  • Improved ActiveX control handling

  • Over a dozen new security options

  • Security status bar (easier and quick identification of Internet problems)

  • One-click Fix My Settings feature

  • Single-click Browser Content Cache Deletion

Another much need security improvement is the default prevention of ActiveX controls from being called though IE when they were never intended to be used in IE. Windows, and other installed applications, contain dozens of ActiveX controls. Prior to Windows Vista, if the installed ActiveX control was marked "safe for scripting," any IE content could launch the control and use it against the system. The new model is an opt-in policy, where all controls are disabled from being able to be launched in IE, except the ones the administrators or end users add as approved.

Windows CardSpace is Microsoft's new way for managing and providing credentials and other information (for example, credit card numbers, personal identity information) to participating Web sites and network resources. Users create individual "cards" (see Figure 1-6), which can then be securely transmitted to requesting sites. When creating and transmitting cards, CardSpace opens on the secure desktop, in order to prevent malicious interactions on the user's desktop. There is a great wiki discussion on CardSpace located at http://www.en.wikipedia.org/wiki/Windows_CardSpace.

Image from book
Figure 1-6: Windows CardSpace can represent credentials for many sites as "cards."

Many reviewers have called CardSpace a replacement for Microsoft Passport services. This is too simple an explanation. CardSpace is an entirely new way of delivering logon credentials and other confidential information between two hosts. Passport is being depreciated and active Passport accounts will be moved into a new Microsoft offering called Windows Live ID.

Note

CardSpace fully supports the new OpenID open standard.

Internet Explorer (IE) 7.0 is a huge improvement over its earlier predecessors. Whether IE can stand up to the volume of attacks that accompanies being the world's most exposed Internet application we will not know until some time passes.

IIS 7

Internet Information Services (IIS) 7 hopes to continue on the very positive security tradition of IIS 6. IIS 7 is an optional component in Windows Vista, but by default is not installed or enabled. The single biggest security change in IIS 7 is the compartmentalization of its code. In previous versions, most features were contained in large monolithic code bases. For instance, regardless of which authentication method you wanted to use for your Web site (for example, Anonymous, Basic, Windows Integrated, Digest Authentication, and so on), the code for all four methods was contained in one file and was loaded into memory together.

IIS 7 changes this by separating the code into individual modules. If you only want to load Digest Authentication, only that code will be loaded into memory. The same thing applies for dozens of other components. The less code that is loaded into memory the fewer potential exploits. This is an idea available in the open source competitor, Apache (http://www.apache.org), for years, but only now being added to IIS.

Configuration and management of IIS has been completely revamped. The dreaded metabase file has been traded in for an .XML formatted file with a simpler interface. Values can easily be directly viewed and edited, and the XML configuration files can be readily copied and replicated. IIS 7 is the focus of Chapter 9.


Securing Windows Networks

Microsoft completely re-wrote the TCP/IP stack from scratch and is increasingly focusing on the idea of domain isolation and more secure networking components. Windows Firewall has been more tightly integrated with IPsec and given outbound blocking ability. Microsoft also introduces many new features that are sure to come under scrutiny by attackers.

Enhanced Network Location Awareness

Windows Vista's networking often focuses on three predefined network domain profiles:

  • Domain

  • Public

  • Private

The Domain profile refers to the network configuration settings while the computer can reach an Active Directory domain controller.

All other network connections are automatically classified as Public until the user (if the user is an administrator) elects to change that classification. Public includes all networks that the computer might be connected to while traveling (such as airport, hotel, café WiFi, and so on), public access networks, open wireless access points at the neighbor's house, and so on.

Note

There is a fourth network domain called Work, which only comes into play if a domain controller on the Domain network cannot be located.

A network can be configured to be Private by the computer's operator or administrator. These three network profiles allow Windows Vista users to quickly define different network and security policies for all three domains, allowing quick "switch-on-the-fly" flexibility.

The Network Location Awareness service attempts to notice when a Windows host changes network locations (for example, roving laptop) or a significant network topology change has occurred (for example, down router, VPN, and so on). Changes in network location can affect many Windows components, including group policy, DHCP settings, and router tables. The algorithms used to detect a network change have been improved. Slow link detection, used in group policy and other features, no longer uses just ICMP.

Network Map

Microsoft has included a great network mapping tool that graphically represents the physical/logical TCP/IP components between the Windows Vista host and a target destination, plus the other devices on the local network. It's a great network troubleshooting tool, and might prove useful when diagnosing a malicious re-direction attack. To do this, Microsoft created a new network protocol, Link-Layer Topology Discovery, and a new service, Link-Layer Topology Discovery Responder.

The Rebuilt TCP/IP Stack with IPv6

Along with rebuilding the entire TCP/IP stack, Microsoft has added stronger support for the long awaited IP version 6 (IPv6), performance self tuning, new APIs for packet inspection (called the Windows Filtering Platform), and a bevy of diagnostic tools. IPv6 has significant security improvements built into the protocol. Finally, after a decade of waiting, IPv6 is starting to gain increased usage, with some countries running the Internet and their own infrastructures entirely on IPv6. Windows Vista can run both IPv4 and IPv6 protocols at the same time, as well as tunnel IPv6 traffic within IPv4 traffic.

Not everyone is happy that Microsoft rebuilt the Windows TCP/IP stack from the ground up. Windows Vista beta testers have found simple, old, network stack vulnerabilities in the beta code (http://www.securityresponse.symantec.com/avcenter/reference/ATR-VistaAttackSurface.pdf). Most of the found vulnerabilities were fixed before release, but critics, particularly those with a vested interest in Microsoft not entirely succeeding in security, pointed out the simple vulnerabilities found (for example, LAND attack) as evidence of an overall lack of maturity in the Windows Vista TCP/IP stack.

Routing Compartmentalization

Host-based routing has become more compartmentalized. An administrator can define separate routing tables for different users or different network locations. For instance, if the PC connects to a VPN, one router table can be created for all VPN-related traffic, and an entirely different router table used for other network connections and locations.

Windows Firewall

Microsoft's enabling Windows Firewall by default in XP SP2 led to an immediate and measurable decrease in the spread of malicious code. Windows Firewall in Windows Vista has been completely rewritten, and includes outbound blocking. The improved Windows Firewall comes with pre-configured exceptions (predefined allowed connections) for many common applications, although the majority are not enabled by default. Exceptions can be configured by source and destination IP addresses, TCP and UDP port numbers, by interface, groups, network domain, and by service account. For more information on the changes in Windows Firewall, see Chapter 11.

Domain Isolation

Microsoft is focusing on network domain isolation. A domain is any predefined network address scope that requires its own access control permissions. Traditional domains represented on the standard network firewall are internal network, DMZ, and external network. Domain isolation just extends to the whole security domain concept to any set of hosts or network devices the administrator wants to define. For example, the marketing and IT computer resources can be kept from communicating with each other. Or the back-end database server can be configured to accept only inbound connections on port TCP 1433 (the SQL Server port, from the DMZ web server). This latter restriction would actually be something called "server isolation," which is a variant on domain isolation. We will discuss domain isolation further in Chapter 12.

Microsoft is pushing administrators to better define their network domains using a least privilege policy, to prevent unauthorized access and malicious behavior. Administrators can use any Windows access control mechanism available, but in most cases Microsoft domain isolation refers to Windows Firewall, IPsec, and, optionally, Network Access Protection (NAP).

NAP requires one or more Windows servers and attempts to restrict attaching network hosts to a limited subset of network resources until they are examined, queried, and approved (for example, is the Windows Firewall turned on, are client patches up-to-date, is client computer running an up-to-date antivirus scanner, and so on). Once approved, they can connect to either the entire network or isolated to particular domains. Microsoft has significantly improved domain isolation and NAP in Windows Vista, and in the forthcoming Longhorn server product.

Improved Wireless Security

Wireless connectivity has been moved into the main TCP/IP stack. Previously, wireless connectivity was a separate client and a separate stack, which meant that many normal networking features did not integrate as well into wireless connections. Windows Vista supports the latest wireless open standards, including 802.1x, WPA, WPA2, PEAP-TLS, and 802.11i. Wireless connections can now get logon scripts and GPO updates, prior to the user logging in successfully (something that did not occur in XP). Wireless security is covered in detail in Chapter 13.

New Peer-to-Peer Networking

Windows Vista contains more peer-to-peer (P2P) and collaborative networking components, including a new Peer Name Resolution Protocol (PNRP). Windows Shared View is a new collaboration program that allows up to ten people to share sessions, applications, and data. From a security standpoint, P2P applications and components, especially the seamless type that Microsoft is promoting, are often avenues for malicious attack.

SMB 2.0

The Server Message Block (SMB) protocol is used for Windows networking. SMB is often associated with folder and printer sharing, but it used throughout Windows for many things, including logging on to a domain, group policy distribution, and remote management. Windows Vista includes a new version of the SMB protocol, SMB 2.0, which improves on both performance and security over SMB 1.0.

SMB 2.0 is more resistant to many attacks, including anonymous connections and MitM attacks. Windows Vista and Longhorn Server will use SMB 2.0 when talking to Windows Vista and Longhorn servers and clients. When talking to down-level clients, they will use SMB 1.0.

One of my favorite new default settings is that Windows Vista no longer looks for and enumerates all local network shares when it boots up. By default, XP Pro, using the browser service will enumerate all shares and printers on the local network when it starts. Although this feature could be turned off, because it is a default setting, it leads to lots of shares being unnecessarily revealed to non-admin users.


Group Policy

Windows Vista contains over 800 new group policy settings. Improved management and configuration settings include:

  • Blocking portable media device installation

  • More Internet Explorer security settings

  • Improved IPsec and Windows Firewall settings

  • Improved administrative templates

  • Improved printer control (location-based, can allow users to install)

  • Improved power management

There are also several new user rights, such as the ability to grant users the right to change time zones. In addition, there are dozens of new security settings.

The Group Policy Management Console (GPMC) is installed by default, no longer requiring a separate download. On the client-side, one of the biggest changes is that group policy application is no longer under the mandate of the Winlogon.exe process, as it is in prior Windows operating systems. It is now its own separate Group Policy Client, with increased reliability, increased functionality, and more intelligence about what to apply when. And, even more important, it has significantly better logging (see the Improved Event Logs section above).

There is a new Administrative Templates format, known as ADMX files (matching their new file extension). ADMX files are "easily" editable XML files, with increased functionality and capable of multi-language support. They will be stored more efficiently in Longhorn server, with ADMX templates being stored in a central Sysvol location, instead of individually being attached to one or more group policy objects. Legacy ADM files are still supported, however.

Another important client-side change is the ability to have multiple Local Computer security policies, instead of the computer having only one. Actually, there is still only one Local Computer policy, but it can have different settings for different users or groups. Chapter 14 will cover group policy in more detail.


64-bit Only Improvements

Windows (and other PC-based operating systems) are quickly moving to 64-bit environments. XP Pro and Windows Server 2003 are available in both 32-bit and 64-bit versions. Windows Vista shipped simultaneously in 32-bit and x64 versions, a first for Microsoft. In the near future, only 64-bit PC hardware will be available for purchase and Microsoft will be strongly pushing 64-bit versions of Windows. In fact, already as of this writing, it seems the majority of desktops are 64-bit capable, although laptops appear to lag far behind, sadly.

The 64-bit versions of Windows are significantly more secure than the 32-bit versions. For one, all boot critical code, including the HAL and OS kernel, is code integrity-checked before running. System catalogs (for example, Nt5.cat) contain the image hash integrity values. In addition, because all device drivers must be re-written to take advantage of the 64-bit platform, Microsoft cares less about backward compatibility and more about making third-party vendors build in security from the start.

This new approach allows Microsoft to mandate things it could not before For instance, all kernel code must be digitally signed by a certificate obtained by Microsoft. This is known as PatchGuard or Kernel Patch Protection. Unsigned code cannot be loaded into the kernel under normal operations. Microsoft is releasing dozens of new tools to third-party vendors so they can check for security problems and stability issues. In 32-bit versions of Windows, unsigned kernel code can be loaded, although it is still not recommended.

64-bit versions of Windows include a 32-bit emulation layer for legacy applications, and contain a virtualized 32-bit registry area for 32-bit applications. Microsoft is doing its best to prevent 32-bit code from touching 64-bit code and memory. 16-bit drivers and programs will not be supported on 64-bit versions of the OS, and can only be hosted by running in virtual sessions. By default, future Windows server versions will include virtualization software built-in. There will be no need to purchase separate virtualization software (for example, Virtual PC, VMware, and so on) for many purposes.


Future Improvements

Microsoft is already hard at work on improving security even more in Long-horn server and the next generations of Windows. Some of the changes include:

  • Improved IPv6 stack and support

  • RDP over HTTP (don't confuse with RPC over HTTP)

  • Application IDs (uniquely identifying the integrity of registry vendor code)

  • Read-only domain controllers (BDCs anyone?)

A much anticipated future security feature is something called Server Core. Server Core will be a supremely stripped down, locked down version of server editions of Windows. It will contain no GUI, and function solely as an infrastructure server. The roles it will play include file server, print server, domain controller, DHCP server, and DNS server. It will be high performance and high security.


Summary

For years Microsoft has been cast as a company that didn't understand computer security. But the tide has been turning and now Microsoft is turning out some of the most secure software in the industry. Since Windows XP Pro SP2 and Windows Server 2003 SP1, Microsoft has been taking increasing flack for pushing too much security too fast on end users, often at the expense of security over functionality. This is quite a change from the past. For those of us with over a decade of experience in securing Windows, we can't believe our fortune. Will Windows Vista finally defeat malicious hackers and malware? Probably not, but it will make the job tough on those who mean to cause others harm.

This chapter covered the most significant new security features in Windows Vista. To recap, the features most likely to make a practical impact on your computing experience are:

  • User Account Control

  • Internet Explorer-Protected Mode

  • Mandatory Integrity Controls

  • BitLocker Drive Encryption

  • Portable Media Control

  • Device/Driver Control

  • 800 New Group Policy Settings

  • More Secure Defaults

  • Harden Services

  • Secure Desktop

  • Startup Repair Tool

  • Improved Event Logs

  • Event Triggers and Event Forwarding

  • IIS 7

  • Improved Patch Management

  • Decrease Risk when admins are logged in

  • Potentially Less Admins Needed

  • Session Isolation

  • Previous Version client installed by default

  • Improved EFS

  • CardSpace

  • Windows Defender

  • Improved RDP authentication

  • IPv6

  • File and Registry Virtualization

  • Improved Crash Diagnostics

  • New Logon API

Believe it or not, as long as this chapter is, there are hundreds of other improved security features that could not be fit in this introduction. Nearly every application, aspect, and feature has been re-examined, starting with an increased focus on the Security Development Lifecycle, threat modeling, and a more secure programming language. Significant security improvements have been made to host applications, booting sequence, logon architecture, NTFS, encryption, Internet security, and networking stack. Windows Vista's new mandatory integrity controls, User Account Control, and file and registry virtualization are truly paradigm shifting changes, which will make Windows an even more secure platform choice.

Upcoming chapters will cover the major improvements in more detail. Chapter 2 describes how attackers and malware exploit Windows, and introduces a few areas of potential weaknesses in Windows Vista.


Best Practices

  • Familiarize yourself with the features that are new or significantly different in Windows Vista.

  • Do not disable security features, at least not until you have given them a try.

Insofar as you can, push your vendors to write software that works well as a non-administrator. Favor software that is properly written over that which is not.


Chapter 2: How Hackers Attack

It is crucial that Windows security defenders understand how malicious hackers can attack and exploit their systems. Only when attacks are thoroughly understood can sufficient defenses be designed and implemented. Thus, this chapter focuses on the major methods of malicious exploitation.

Malicious Exploitation

Microsoft Windows is the most attacked PC desktop OS in the world, coming under attack from both dedicated hackers and automated malicious software. Regardless of whether the attack is occurring as a results of skilled human hands or pre-programmed malware, both methods use one of eight techniques to exploit a computer.

Logon credential guessing/cracking OS or application misconfiguration

Eight Exploitation Techniques

  • Logon credential guessing/cracking

  • Buffer overflow

  • OS or application vulnerability

  • OS or application misconfiguration

  • Eavesdropping/man-in-the-middle attack

  • Denial of service attack

  • Client-side attack

  • Social engineering

There are many different types of attacks, but these are the major ones. The next section of the chapter covers each of the techniques in more detail.

Logon Credential Guessing/Cracking

Logon credential password guessing and cracking are among a hacker's (or worm's) favorite attacks. Many sources call this technique "password cracking," but that name is an oversimplification of the subject. First, users don't always use passwords in their logon sequence. They can use passphrases, biometrics, smart cards, fingerprint scanning, digital certificate, or some other form of logon authentication. With that said, most logon authentication is password-based. Second, if the attacker has to guess the user's (or computer's) logon name (i.e., identity label) as well, it is more accurate to call it "credential hacking" than "password hacking." There is also a difference between guessing and cracking.

Password Guessing

Password guessing is literally guessing at the password, whether manually or by using an automated program. Guessing is done against an active logon interface. In Windows, if the appropriate services are active, it can be done against many server applications, including the normal Windows logon, RRAS VPNs, NetBIOS, Remote Desktop, Remote Assistance, Terminal Services, SMTP, POP, IMAP, MS-SQL, FTP, Telnet, and Web sites (if an HTTP authentication method besides anonymous is turned on)-basically, anywhere the attacker can get a logon prompt, including any third-party utilities (for example, PC Anywhere, VNC, Hyena, and so on).

Guessing is very common, but slow. It must be performed against a logon GUI or text-based prompt, and each guessing attempt must wait for the logon service to respond successfully or not, before starting the next attempt unless multiple sessions are used. Often the quickest logon attempt interval is 1–2 seconds at best. While that might not sound slow, it is too slow if the attacker has to guess millions of different passwords.

Automated Password Guessers

Many password-guessing crackers use software tools to automate the task. A password-guessing program can input password after password against a logon screen until the passwords it is guessing are exhausted, the account is locked out, or the cracking attempt is successful.

Another benefit of automated tools is that they can often start multiple login sessions at once. Some tools let the attacker start any number of logon sessions that the attacker wants, limited only by network bandwidth (if the guessing attempt is being done over a network connection) and the processing capability of the computer being attacked. Of course, as the attacker increases the number of simultaneous attack sessions and guesses, the chances of being detected increased. In practice, most attackers limit the number of concurrent logon sessions to fewer than two dozen. Some computer services will fail to accept more than 1 or 2 at a time. If an account lockout mechanism is enabled, the attacker may be forced to limit the guessing to 1 or 2 passwords per 5-or 10-minute period, so the attacker doesn't disable the used logon account. How many guesses and sessions are allowed depends on the service being attacked and the logon security used.

The most popular automated password guessing program in use today is The Hacker's Choice's Hydra program (http://www.thc.org). Hydra is a command-line program that is available for Windows, Linux, PDAs, and cell phones. It allows an attacker to guess at multiple user names, with multiple password guesses, against multiple servers, all at once. It supports dozens of logon services, including those Windows services mentioned previously, plus Cisco, MySQL, Oracle, and many more. Figure 2-1 shows Hydra running against a Telnet service.

Image from book
Figure 2-1: Hydra automated password guessing program being used against a Telnet service

Password guessing can be easier if the target's password policy is known. For instance, suppose the password policy says that the minimum password size is 6, must contain one uppercase letter, and must contain at least one non-alphabetic character (the same as Vista's default password complexity policy). If the minimum password size is 6, most users' passwords will be six or seven characters long. If it must contain an uppercase letter, most users will put the capitalized letter at the beginning of the password. And if a non-alphabetic character is needed, most users will choose the numbers 1 or 2, or choose among the following commonly used symbols: !@#$.

If the user can choose his or her own password (versus having a computer randomly select it), it will more than likely be a complete word or have a root that is nearly a complete word, name, or subject. This makes the password easier to remember. For example, given the preceding password policy, common passwords might be Password2, Football!, Michael1.

Types of Password Guessing

If a password attack just begins guessing by using all the possible symbols that might be in a password (for example, a, aa, aaa, ab, abb, bbb, and so on) instead of whole words, it is considered to be a brute force password attack. Brute force attacks are computationally the most difficult of password attacks to pull off.

Most users use a password with a common word root (for example, frog, password, guess, and so on). Password guessing attacks that guess using complete words that might appear in a dictionary are known as password dictionary attacks.

Often password polices force a user to include some additional characters (for example, numbers or symbols) to defeat password dictionary attacks. Most users end up with passwords that have a common word root, but contain additional characters (for example, Frog2, Password32, P@ssw0rd, and so on). Password attacks that guess using common dictionary words that are then given additional complexity are known as password hybrid attacks.

In general, brute force attacks are used only when the attacker has no idea of the potential passwords or their complexity. Password dictionary attacks are very common, and often are the only real choice when time is of the essence. Hybrid guessing attacks are mandatory when the password policy disallows simple dictionary words.

It helps the attacker considerably if he has an idea of what the password might be, such as the user's personal information or hobby. It is common for users to include their children's names or loved one in their password. If onsite at the user's computer, an attacker would look for the pictures of the people displayed closest to the user's desktop. Hobbies and sports are often used as passwords. For CEOs always try something related to golf or the car they drive. When in Washington, D.C., always try Goskins!. When in Chicago try Gobulls!. You would be surprised how often the latter two work when in those towns.

Password Dictionaries

Password guessers/crackers often use a password dictionary file, which is a collection of potential passwords to be used in automated attacks. The best password dictionaries contain all the possible complete words in the user's native tongue, plus hybrid variations that include near-spellings, mixed case-sensitivity, and so on.

The best English password dictionary the author has come across was 87,000 words. The number of total words in the English language is over 877,000 (http://www.languagemonitor.com). So, the best password guessing dictionary contains only 10 percent of the possible words. But in practical use, most users have a working vocabulary of under 10,000 words. Still, the better the password dictionary is, the more likely the attacker will be at guessing and cracking passwords.

Anyone can search for and find password dictionaries on the Internet. Once when I was having a hard time cracking administrative and root passwords on a particular network, I learned that the network administrator was a big Star Trek television show fan. I downloaded a Klingon-based dictionary file and cracked all the admin passwords in a few minutes.

Problems with Password Guessing

There are three major problems with password guessing: length of time, account lockout, and event logging. If the user account being attacked has a complex password and the attacker doesn't know the password policy or have hints about the possible password, it could literally take millions of guesses to get the correct password. Even with an automated password guessing attack, it could take years (if ever) to successfully guess a correct password.

Further complicating the issue is the password guessing defense of account lockout. The term "account lockout" describes any logon mechanism that disables an otherwise valid logon account after a predetermined number of successive bad password attempts. The lockout can be temporary (for example, 1 minute long) or remain in a locked out state until an administrator resets the account lockout password counter mechanism. Also, even if account lockout is not enabled, many operating systems and services, including the Windows logon service, will delay future logon tries for a random time period (usually only a few seconds) after multiple bad passwords have been attempted. This is known as an "anti-hammering" defense.

Any good logon mechanism should be monitored for failed logins. Often a high number of successive password failures will generate a "bad logon" event message, which the administrator can view or be notified about. When any of the three issues just described (excessive length of time, password complexity, or account lockout) is involved, most password attackers would rather crack than guess.

Password Cracking

Password cracking involves capturing the password in an obscured form (for example, hashed, encrypted, and so on) and then computationally converting the obscured form back to its plain-text original. For example, Windows logon passwords are stored as password hashes in the authentication databases. If the password hashes can be obtained by an attacker (more detail on this in Chapter 3), the hashes can be computationally attacked and converted to their plain-text equivalents. When you hear the term "password cracking," this is what they are talking about.

Traditional password cracking works by taking a plain-text password guess, hashing it using the same hashing algorithm as the captured password hashes, and then comparing it to the extracted password hashes. If the newly computed hash and captured hash agree, then a plain-text password match is found.

In order to get the Windows logon password hashes, typically the hacker needs administrative access to the computer she is attacking or local physical access. With administrative access, it is possible to obtain the hashes locally or remotely. The attacker can also obtain the password hashes by sniffing the network communications between users and computers, and their remote authentication servers. Last, if BitLocker Drive Encryption (discussed in Chapters 1 and 5) is not enabled, the hacker can obtain the password hashes by accessing the Windows computer locally and physically copying the authentication database to portable media.

The major benefit of password cracking, once the original hurdle of how to obtain the password hashes is overcome, is speed. Many password cracking tools can do tens of thousands to over a million password cracking computations a second.

Two of the most common password hash-cracking programs are John the Ripper (http://www.openwall.com/john) and Cain & Abel (http://www.oxid.it/cain.html). John the Ripper is the more popular of the two, and works on Linux, Windows, and other platforms. It is a very fast command-line utility. It can crack Windows, Linux, Cisco, and other password hashes. It also has a distributed version, Distributed John (http://www.ktulu.com.ar/en/djohn.php), which can split the overall computational workload over multiple computers.

Cain & Able is a Windows-only GUI program that is capable of cracking over 25 different types of password hashes, including Windows, Cisco, and MS-SQL hashes. Cain & Able isn't as fast as John the Ripper, but with its click-and-point GUI, it's a lot prettier and easier to use. Figure 2-2 shows Cain & Able cracking a short 6–8 character password. Trying over 2 million calculations a second, Cain & Able will be able to crack the password in 15 days if the password is only 6–8 characters long and contains only the characters Cain & Able was instructed to use in the attack.

Image from book
Figure 2-2: Cain & Able being used to crack Windows password hashes

Depending on the password's complexity, password crackers may have to try millions, and even millions of trillions of hash computations. Again, knowing the password policy and using a password or dictionary attack is often the best way to compromise the password.

Two relatively new techniques have made password cracking even faster. One uses pre-computed hash tables. With this method, every possible plain-text password (or likely subset thereof) is generated beforehand, hashed, and placed into a database lookup table. Then the attacker inputs the captured hash into the accompanying cracking program, it looks up the identical hash, and displays the plain-text password.

However, pre-computer hash tables can be very large, gigabytes big just to list the short ordinary password choices; and slow to generate. It then takes gigabytes of permanent storage and memory to use the table. An even better technique using rainbow tables (http://www.en.wikipedia.org/wiki/Rainbow_table) is now often used to crack certain types of captured password hashes (including Windows password hashes) faster.

Hashing algorithms are long and complex. Hashing all the possible passwords is a very time-intensive process. Rainbow tables use reduction algorithms (that are less computationally intensive) against password hashes. Essentially, Rainbow table programs are able to use the reduction function against the captured hash and compare it to other stored results of the reduction functions that were pre-computed and stored, and find much faster matches than using regular pre-computed hash tables.

Attackers can create their own rainbow tables (see http://www.rainbowcrack.com), download other people's tables (http://www.rainbowtables.shmoo.com), purchase them online, or even use an online rainbow table hash cracker (http://www.lasecwww.epfl.ch/~oechslin/projects/ophcrack). Password matches can often be made in seconds.

The side benefits of password cracking come from the fact that the password guessing is not done against an online database or against an active logon session. Hence, account lockout and event logging are not an issue. The hardest part of password cracking is obtaining the password hashes in the first place. As passwords get more complex or longer, they become increasingly resistant to password guessing and cracking.

Other Password Hacking Methods

Passwords can be compromised several other ways, including keylogging, shoulder-surfing, sniffing the network, replaying, man-in-the-middle (MitM), and social engineering. Keylogging involves placing a hardware device or a trojaned executable on a user's computer and then capturing the plain-text password as it is typed in. The captured password can then be stored in a local file and picked up by the hacker using another installed backdoor program, or sent to the hacker via IM or e-mail. A large percentage of malicious mobile code (for example, viruses, worms, Trojans, and so on) now include this functionality.

Passwords can be stolen simply by looking over the legitimate user's shoulder (referred to as shoulder surfing). Shoulder surfing is particularly useful in environments that use small passwords (for example, four-character PINs used with ATM and debit cards). Hackers have even installed hidden cameras at ATM locations to record users' PIN numbers.

The attacker can sniff the network to learn passwords or password hashes. Many protocols (for example, Telnet, FTP, POP, SMTP, and so on) will send passwords in plain text by default, with no effort made to obscure. Many password crackers, such as Cain & Able (mentioned previously), can sniff plaintext passwords or password hashes. In Figure 2-3, Cain & Able is displaying captured plain-text FTP passwords.

Image from book
Figure 2-3: Plain-text FTP passwords caught by Cain & Able using network traffic eavesdropping techniques

It is the rare network that has very strong passwords used by all users throughout the environment. In one onsite penetration I was involved in, the password policy required long and complex passwords, and even biometric fingerprint readers for Windows logons. But a Microsoft SQL server's sa user (i.e., SQL system administrator) account had a blank password. After discovering the blank password, the author was able to take over the entire network within 15 minutes. So, even in networks requiring strong passwords, no one database holds all the logon credentials. It's hard for the defender to be perfect, but the attacker only needs to be persistent.

Sometimes the easiest way to get a password is just to ask the user. Often, with just a little bit of coaxing, end-users will give out their real passwords to complete strangers. Several studies have been done demonstrating that a large percentage of randomly chosen users will give out their real network passwords for a cheap gift, such as a $2 pen or a chocolate candy bar. Password attacks, whether guessed, cracked, or socially engineered, are one of the most popular types of attacks.

Buffer Overflow

Most applications and operating systems contain one or more buffer overflows. Attackers can discover them accidentally, or use buffer overflow finding programs (for example, static code review tools, fuzzers, and so on) as discussed in Chapter 1. Once a buffer overflow is discovered, it can be used by almost anyone with knowledge of the buffer overflow and access to a vulnerable service. A buffer overflow is normally exploitable from the time it is found until the vendor releases a patch, or the administrator takes some other offsetting steps (for example, IPS, turning service off, using alternate program, and so on).

Unfortunately, vendors are often slow to respond with patches and many users are slow to apply them even when available. It is not unusual for a vendor to take weeks to respond to a reported bug. To be fair, it might take weeks for a vendor to create and test a reliable patch. When the patch is released, most production environments have to regression test the patch before applying to make sure it doesn't break existing applications. In most cases, a mid-size or larger company might take one to two weeks to apply a new critical patch even if they are actively following vendor vulnerability announcements and testing patches. Some people and environments never install patches-ever! And until the software is patched, it is open season for attackers.

Buffer overflows often give the attacker remote access to the attacked computer within the security context of the program or service overflowed. Most Windows services run in the System context, which means a remote buffer overflow might give the attacker a highly privileged session. Once the buffer overflow is accomplished, most attackers "shovel a shell" back to their originating computer. The new command-line shell gives them a text-based logon session to the exploit computer. Then the attacker can contact the machine, upload and download files, and manipulate the victim computers however the attacker wants. Some buffer overflows create only denial of service (DoS) conditions, where the service is locked up or unavailable to legitimate users until the service is re-started.

Literally thousands of buffer overflow attack programs are available on the Internet. One of the most popular Web sites for downloading buffer overflows is http://www.milw0rm.com (see Figure 2-4). It contains buffer overflows for Windows, Linux, Unix, Solaris, and many other platforms.

Image from book
Figure 2-4: Milw0rm Web site

Metasploit Framework

Many buffer overflow programs are ready to go, others you have to compile, and others are scripts just waiting to be launched. And today, buffer overflow attacks can be launched using a few clicks of the mouse. The Metasploit (http://www.metasploit.com) project has produced an easy-to-use vulnerability testing tool called the Metasploit Framework (http://www.metasploit.com/projects/Framework). It works with Windows, Linux, Unix, BSD, and Apple platforms.

Note

If you decide to use Metasploit Framework, or any vulnerability testing tool, make sure you have the permission of the computer's owner.

The Metasploit Framework (MSF) is a vulnerability testing environment, which comes with over 140 exploits and over 75 payloads (actions to take after the initial exploitation). MSF contains dozens of Windows exploits, and often buffer overflows will be included in the product within hours of a public exploit announcement. MFS comes in both command-line and GUI forms. The web-based GUI makes exploitation literally four clicks of the mouse (see Figure 2-5).

Image from book
Figure 2-5: Metasploit Framework web interface

Buffer overflows can be used remotely (for remote control or DoS purposes) or locally for privilege escalation attacks. Suppose the attacker can get a local or remote logon, but only in the security context of a non-admin user. The attacker needs to get Administrator-or System-level security levels to make sure he has complete control of the exploited user and/or computer. Privilege escalation buffer overflow attacks allow the attacker to run one program and be immediately elevated to Administrator or System. If buffer overflows are possible, they are among the easiest methods to attack with. Just run the buffer overflow program and gain access. The best defense against buffer overflows is to make sure the OS and any installed applications are up-to-date with patches.

OS or Application Vulnerability

Even if the OS or application doesn't have a buffer overflow, they both can still contain bugs that allow unintended consequences that lead to new vulnerabilities. Vulnerabilities include:

  • Privilege escalation

  • Information disclosure Data malformation

  • Unintended consequences

There are many other types of vulnerabilities, but these are among the most common. The sections that follow will discuss each in a little more detail.

Privilege Escalation

Attackers often use vulnerabilities to gain a higher privilege level. Most applications run in the security context of the user, meaning that if an attacker takes over the application, they are limited to the security permissions and rights of the involved user. Malicious hackers have used hundreds of tricks to get to Administrator or system status.

A common example in Windows XP was for non-admin users to use the Task Scheduler (or At.exe command) to schedule a job to run the Cmd.exe command interactively. When the job ran, the interactive status would run it in the System context and a command-prompt session with full system access would be started.

Another common example involved opening up an application's help file. Although the application was running in a user's context, when the application's help file was opened, Windows opened the Windows Help application in the System context. Unsuspecting users would just see the displayed text file, but hackers would use the now opened help file to gain access to Cmd.exe with System access.

Another popular example is that of using one application's security features against another application. By default, non-admin users cannot change Internet Explorer's security settings. It was discovered, however, that if those same Internet security settings were accessed using older versions of Windows Media Player, they could be changed. Turns out that the Windows Media Player application accessed the Internet Explorer security settings using the System account instead of its own started privileges.

Information Disclosure

It is also common for error messages in applications to reveal too much information. It is not uncommon for web application errors to reveal the scripting language used, back-end database management system used, file names, directory paths, and more. Any of this information can be used by an attacker to gain more access and aid with social engineering situations. According to Secunia, 7 percent of all successful attacks against Windows XP Pro have been information disclosure attacks (http://www.secunia.com/product/22), and 18 percent of Mac OS X attacks (http://www.secunia.com/product/96). Programmers should take great care to make sure that application errors do not reveal too much information to unintended parties.

Data Malformation

All applications should treat all inputted data as untrusted. Inputted data should be checked for maliciousness, and abnormal data sanitized or dropped. Data malformation can interact with applications in strange ways, sometimes leading to a co-mingling of instructions in data fields, which the application then executes. Examples of data malformation co-mingling attacks include: SQL injection, cross-site scripting (XSS), and URL re-direction.

XSS attacks are very common. In an XSS attack, an innocent victim Web site or HTML-enabled service (for example, web-based e-mail) accepts as data input anything any user types and is able to render the typed in data as HTML code. A malicious attacker will type in or input scripted commands (usually Javascript) as data that then gets executed in the browser of any viewing user. The web application is expecting the user to type in text, but instead the malicious user types in scripting commands that get executed on other unsuspecting users.

In order to prevent XSS attacks, programmers must program their applications to check for, and remove, text that could incorrectly be executed as commands or scripts. For example, a web-based program can check user input for and remove </ anytime it appears. Those two symbols often precede embedded scripts.

Unintended Consequences

Software can be used in ways the vendor did not intend. Unfortunately, too many vendors don't use threat modeling to write more secure code, and even if threat modeling is used, not all the future misuses can be predicted. For example, ActiveX controls are compiled executables that can be distributed and executed using web-based browsers. When an ActiveX control is marked "safe for initialization" and "safe for scripting," it means the vendor feels the ActiveX control can't be used maliciously. ActiveX controls are frequently instructed by malicious commands to do something harmful to an exploited system.

For example, Symantec Norton Antivirus contained a control meant to be used by the application and Symantec tech support. Instead, hackers learned that anybody could call and use it (http://www.securityresponse.symantec.com/avcenter/security/Content/2004.05.20.html), and be able to launch applications and execute arbitrary code. Several other vendors allowed the same thing to happen, including HP (http://www.computerbytesman.com/acctroj/hp.htm) and Compaq (http://www.internetnews.com/dev-news/article.php/740501).

OS or Application Misconfiguration

Complexity is the antithesis of good computer security. It's easy for an administrator or end user to choose a single application configuration option and accidentally open up the computer to attack. For instance, when applying new permissions in Windows NT 4.0, it was common to get a dialog box asking if Windows was supposed to replace all files, folders, and child objects with the new permissions. In most cases, the answer probably should have been no, because doing so replaced all previous permissions with the new permissions, when the user often just meant to add one new permission. Microsoft realized that the interface was being misunderstood and re-designed the interface to prevent easy misconfiguration. Other common misconfiguration examples include:

  • Not changing vendor default passwords

  • Installing unnecessary software and services

  • Services that install themselves with too many security privileges

  • Remote logon console left unsecured

Although users are often at fault for these types of attacks, vendors can help by ensuring that healthy defaults are used. For instance, with earlier versions of Windows, Microsoft used to install IIS with every feature enabled even though most users did not intend to run a web server. Subsequently, early versions were exploited fairly frequently, often using features that only a minority of users would have ever intentionally installed. With IIS 6, Microsoft learned its lesson and didn't install it by default, and even when installed, it installs with a bare minimum of features. This strategy led to IIS 6 being proven as one of the most secure web server products every built.

Defenders can use vulnerability testing tools, such as open source Nessus (http://www.nessus.org), Metasploit Framework, or commercial products, like CORE IMPACT (http://www.coresecurity.com/products/coreimpact) to analyze and test their computer hosts before the malicious hackers do.

Eavesdropping/Man-in-the-Middle Attack

Hackers can capture and analyze network communications traffic, looking for passwords, password hashes, and program instructions. These types of attacks are most easily accomplished on local area networks (LANs), but can be accomplished anywhere the hacker can locate his network listening tool between the sender and the receiver.

One of the most common eavesdropping tools is Wireshark (http://www.wireshark.org), formerly known as Ethereal. It is a comprehensive, powerful, network sniffer and protocol analyzer. It is available for most platforms, including Windows, Linux, Unix, Mac, and BSD.

Many network eavesdropping tools can listen into traffic and automatically identify passwords and password hashes. Cain & Able (mentioned previously), LophtCrack (popular past commercial tool that is discontinued now), Ettercap (http://www.ettercap.sourceforge.net), and Dsniff (http://www.monkey.org/~dugsong/dsniff) are common sniffing tools that can easily identify passwords in network traffic. Kismet (http://www.kismetwireless.net) is one of many tools that can sniff WiFi wireless traffic.

If the attacker can listen in on traffic between two network nodes, he usually can also perform a man-in-the-middle (MitM) attack. Malicious hackers using a MitM attack can change the data sent and received between the two nodes. For instance, a MitM attack can be used to redirect a user away from their legitimate work Web site to a forged, look-alike, Web site. Many hacking tools, including Cain & Able and Ettercap, make this sort of attack trivial to accomplish on the local network. In Cain & Able, it literally takes only about 30 seconds to pull off a full-fledged MitM attack, with DNS redirection and data manipulation.

Denial of Service Attack

An attacker can cause harm without ever modifying or touching the intended victim. If the malicious hacker can bring down any network device between the legitimate customer and the intended server, it causes damage. At the very least, a DoS causes a local denial problem. Many of the vulnerabilities found in Internet Explorer are local denial of service attacks. The end-user is tricked into running a malicious file, and the file locks up Internet Explorer until the browser is restarted or the computer is rebooted.

An attacker can do the same thing remotely to a server. Early on, DoS attacks were created by overwhelming the target server with millions of illegitimate packets. Even if the packets are invalid, the server's processing time and memory can be taken up to an extent that it can no longer respond to legitimate traffic.

Often all it takes is one malformed network packet and the answering host gets immediately put into incredibly high constant CPU utilization or runs out of memory trying to handle the unusual event. In the past, it was found that sending a single unexpected ASCII character to a Microsoft SQL server port was able to DoS the entire server (http://www.ngssoftware.com/advisories/mssql-udp.txt).

Another common successful single packet attack against Microsoft TCP/IP stacks was the LAND attack. With LAND attacks, a malicious packet is sent to a server containing a source IP address and source port number that is identical to the destination host's IP address and port number. When XP Pro's IP stack was re-written to make it hardened against network DoS attacks, somehow, it became vulnerable (after years of not being) to the LAND attack. The same thing was found in the Vista beta 1 TCP/IP stack by Symantec (as mentioned in Chapter 1). I have also found Windows embedded devices, PDAs, and Microsoft-enabled IP TVs vulnerable to LAND attacks. Because LAND attacks have been around for over a decade and are programmatically easy to prevent, it is always surprising when Windows is still vulnerable to it.

Denial of service attacks are most troubling when they are able to be sent against a remote server and make it unresponsive to legitimate traffic. Local DoS attacks that lock up only a single application are less problematic. The offended user learns not to execute or launch whatever it was that caused the DoS in the first place. Still, any found DoS represents a legitimate bug and weakness in the application. Often DoS attacks are able to be elevated to buffer overflows, which can then be leveraged into a total malicious compromise.

Client-Side Attack

Client-side attacks generally involve tricking the end-user into running malicious code on their local workstation. The vast majority of malicious attacks today are client-side. If the end user can be tricked into running malicious code, no defense, no operating system, no application can be trusted to stop it-especially if the user is logged in as Administrator.

Common client-side attacks include:

  • Malicious e-mail attachments

  • Rogue Internet links

  • Malicious files sent via Instant Messaging

  • Games with embedded Trojan executables

  • Malformed multimedia files with malicious scripts and programs attached

This is the area that received the most attention from the Vista security development team. By default, even when end users are logged in as Administrator, they don't run with Administrator privileges and permissions. And if a program "escapes" out of an application, like Windows Mail or Internet Explorer, it will do so in low or medium integrity and have a hard time accessing the local system files.

Social Engineering

Client-side attacks are generally a form of social engineering, but this section refers strictly to cases where the malicious hacker sent no malicious code. They just asked for the unauthorized information, password, or access. One of my favorite social engineering stories is one I saw first hand when assisting a large university library system on the East Coast with hardening their computers against student maliciousness. While touring the library, the university host and I saw a bulletin board advertisement in the science hallway advertising a new IT support help desk phone number. At the time, I didn't think anything about it, and my host said nothing about it. A month later it was revealed to have been a student's dormitory phone number. He took calls night and day asking for the user's logon name and password to "assist" them. The student was able to collect hundreds of logon names and passwords in little over a month. When the former host called me to tell me about this social engineering attack, I asked why the host (a member of IT himself) didn't recognize that the new number wasn't a valid IT support phone number. The host replied that he often didn't know what was going on in IT and often found out about it through indirect means. He was delighted that they were getting student intern help.

Another common social engineering ploy the I use is to go to the company CEO's executive assistant and ask for the CEO's password. I introduce myself thus: "Hello, I'm Roger Grimes from XYZ Corp and I've been hired by IT to measure the password security of the company. I need the CEO's password." How often has it worked? Every time over the last 5 years.

Another common social engineering scheme is to leave "infected" media around the company. Many penetration testing companies have used this ploy. One left USB flash memory drives scattered through out a smoking area. My favorite is to leave a CD-ROM disc labeled "Pending 2007 Layoffs" in the IT or management area. The left media contains a proprietary "Trojan" that is not detected by any antivirus scanner, and "phones home" using port 443 using an SSL tunnel. Firewalls never stop it. IPSs, IDSs, and antivirus scanners never detect it. And certainly the end user and IT never detect it. When the media is run, it installs a remote access back door. If you allow your end users to install any software they want, then your company is also susceptible to this type of social engineering.

These types of maliciousness can be done by a dedicated manual attacker or using malware.

Dedicated Hacker Methodology

When most people think of hacking, they think of the dedicated human attack manually attacking a computer system. And while this still happens, it is important to realize that it constitutes a small minority of the malicious hacking activity in the world. But small doesn't mean not dangerous.

The dedicated hacker can take its time with the targeted network or computer. Hackers can change their techniques and payloads based upon newly learned information. Here are the traditional steps that a human attacker uses to exploit a system:

  1. Scans for active IP addresses on intended victim host or network.

  2. Fingerprints host operating systems.

  3. Scans for and documents active listening TCP and UDP ports.

  4. Enumerates each found TCP and UDP to determine what service is running.

  5. Uses one of the eight methods listed in the previous section to compromise the victim host or network.

  6. Hacker elevates their privileges to root, Administrator, or System, if they are not already in as such.

  7. After successful exploitation, hacker copies additional hacking tools and hides their presence.

  8. Hacker modifies victim system in a way to ensure they will be able to get back in.

  9. Hacker steals information and/or sets up remote control mechanism.

  10. Hacker pillages and plunders compromised system to find out more information on other hosts and networks (if desired).

  11. Hacker then compromises additional hosts or networks (if desired).

For example, hacker scans an IP address range registered to an intended victim, and finds one or more active IP addresses. The hacker runs Nmap (http://www.insecure.org/nmap/index.html) or Xprobe2 (http://www.sys-security.com/index.php?page=xprobe) tools to identify the underlying victim host OS.

Nmap is used to map and identify the services running on listening TCP and UDP ports. Nmap finds TCP port 80 open, and running IIS 5. The attacker then uses one of eight previously mentioned exploitation techniques. For this example, let's assume they used an unpatched buffer overflow. The overflow gives the attacker local System access.

The hacker uses the local System access to copy up their hacking tools as a single, password-protected Zip file. The files are hidden in the \Windows \Font folder. A backdoor is installed. It is renamed Svchost.exe and uses stealth technology to hide.

The attacker uses its new system access to dump local service account passwords. One of the service accounts belongs to a popular backup tape vendor. The service is used to allow remote backups of workstations to the tape backup server. It is infrequently used, but installed on all computers in the Active Directory forest. The service runs in an Administrative context. The attacker uses the newly found service credentials to log on to a forest root domain controller that also functions as the PDC emulator (i.e., holds the master password table).

The hacker uses the admin-level credentials to dump all the password hashes of the Active Directory database. They then use John the Ripper to crack all the passwords. Dozens of new passwords are found. The attacker plants remote access Trojans all throughout the network, downloads confidential files, deletes mission critical files, and captures the personal logon banking credentials of several employees who used their work computers to check their online bank balances. The hacker also has several personal and corporate credit card numbers.

The hacker then uses the newly gained knowledge to break into other trusted partner networks. New customer accounts are stolen, business-to-business networks are exploited. Within a few days, the hacker has everything it needs. It erases any logs recording its activity and even password encrypts the tape backups using passwords not known by the company's IT staff. Then the hacker deletes all malware and all traces of its maliciousness. By the time the company even knows there is a problem, the hacker is gone.

This scenario, and ones similar to it, are played out hundreds to thousands of times each day. In truth, the dedicated hacker is difficult to defend against. A defender must be perfect; a dedicated attacker just needs to be patient. For example, a dedicated attacker can learn all the software that is running on a particular system, even what defense tools are used. Over the course of a year, the victim's network will need patching several times to prevent exploitation. When a new patch comes out, it can often take several days to two weeks before the patch is tested and deployed. During all that time, the attacker can be exploiting vulnerability. Even as dangerous as a dedicated attacker is, even more common is automated malware.

Automated Malware

Automated malware includes malicious mobile code of any kind, including: viruses, worms, Trojans, bots, spyware, and adware. There are many other types, and hybrids, but these are the main types.

Computer Virus

A computer virus is any program that modifies other legitimate host files or code in order to spread itself. Usually it modifies a file, adding itself to the host file in such a way that when the host file is run, the virus is also run. Viruses often go memory-resident and can infect any executable (or data type in the case of viruses, like macro and script viruses).

Computer viruses were very popular for nearly two decades, but became less successful when Microsoft introduced the Windows File Protection (WFP) in Windows ME and Windows 2000. With WFP, when any changes are made to protected executables, Windows replaces the modified copies immediately with a known good copy. This effectively prevented computer viruses, which must infect other host files to survive and spread, from being able to infect Windows system executables. While viruses could infect non-Microsoft files with system impunity, it made the job of spreading harder to do without being foiled and detected. Eventually, malicious coders decided to focus on malware types that did not need to modify other host files (or boot sectors) to survive.

Computer Worm

Computer worms are self-contained, self-replicating malicious programs. They do not directly modify other host programs or other legitimate coding to spread. Instead, they contain their own replication code and use the legitimate features (for example, e-mail, file shares) to spread.

Currently, computer worms are the most popular type of malware. Computer worms containing remote buffer overflows are responsible for the majority of the most popular attacks in the 21st century so far, as demonstrated by the Slammer SQL server and MS-Blaster worms. Slammer has the title of the fastest spreading worm so far: 90 percent of the possible hosts on the Internet were infected in 10 minutes (http://www.caida.org/publications/papers/2003/sapphire), but no security experts expect that record to go unchallenged in the future.

Trojan Horse Program

Trojan programs pretend to be one type of legitimate program, but instead contain malicious coding. The program the user is executing can be purely Trojan code (called a direct action trojan), or contain both a legitimate and illegitimate program. The user executes the Trojan file expecting to see another sort of program, utility, game, or multimedia content. The expected content is run along with the Trojan code. The user does not expect that a malicious program has been loaded, and will even kindly send it onto other friends and co-workers.

The key defining points of a Trojan are that it pretends to be another type of program, and that it has no self-replicating mechanism. It relies upon end users sending the program to each other to spread. Viruses, worms, bots, and other types of malware often masquerade as legitimate programs, meaning they have Trojan-like features as well. We call these sorts of programs, with multiple classifications, hybrid malware. For instance, an e-mail attachment arrives claiming to be a file the user was waiting for. The user installs it (i.e., it's a Trojan at this point). The Trojan installs a worm to spread via e-mail, and drops a computer virus just to add to the fun.

Bot

Bot is short for robot code, and used to be known as remote access Trojans (RATs) or zombies. Essentially a bot is a Trojan program that is able to take full control of a computer system. The initial compromise is done using a virus, worm, or Trojan. After the initial exploitation, it often contacts another compromised computer that is temporarily acting as a mothership web server. It is able locate the mothership server through a predefined DNS name that is temporarily hosted on a dynamic DNS server. Then the bot downloads either new instructions or a new program, and the process repeats multiple times (see Figure 2-6). At some point, the updating is considered completed, and the bot awaits instructions from its originating hacker. It may be instructed to act as spyware or adware, steal identity information, or be used in a massive distributed DoS (DDoS) attack.

Image from book
Figure 2-6: Bot phoning home

Bots are a large majority of the malware in use today. Their multiple download/updating scheme makes them very hard to track forensically. Many auto-delete themselves after successfully carrying off their missions.

Most bot hackers control tens of thousands of compromised computers in massive bot nets. Bot nets with over a hundred thousand, and even 1.5 million infected hosts are not rare. The hackers use the bot nets themselves in criminal enterprises or rent them out to other criminals. They literally advertise their available and offer 2-for-1 and first hour free sales.

Bots can be detected and removed just like any other malware threat, but their massive sizes often make them easier to detect and remove by the carrier network hosts and ISPs. There are even commercial solutions available to detect and remove bot networks, including products from http://www.simplicita.com.

Spyware

Spyware monitors and records a user's computer activity. It comes in two forms. One form targets the authorized monitoring market, such as parents monitoring children's Internet activities, employers monitoring employees, and spurned spouses monitoring adulterous loved ones (the last category is often not legal). This class of software often installs itself directly on the host computer it is monitoring, and then records every logged in user's keystrokes, e-mails, and chats. The most popular software vendor in this category is Spectorsoft (http://www.spectorsoft.com).

The more worrisome spyware category is one where the spyware is installed without any user's approval by an unknown, unauthorized third party. Spyware is often used by criminals to record users' identity information, passwords, credit card information, and banking information. The vast majority of malware programs are used for criminal intent. See http://www.symantec.com/enterprise/threatreport/index.jsp for more detail.

Adware

Compared to the other forms of malware, adware almost seems harmless. Adware installs itself through the normal mechanisms (virus, worm, Trojan, and so on) and then records the Internet sites and content a user visits, or goes even further to redirect (without authorization) the user to other Internet locations. Adware normally modifies Internet Explorer, but can also maliciously manipulate DNS client services.

Adware makes its money by getting people to visit sponsored Web sites and advertisers. The adware hacker usually make up to ten cents per every sponsored visit. By installing the adware on multiple computers (much like a bot net), the adware hacker makes money. In most cases, the infected user isn't maliciously harmed, other than being re-directed away from other legitimate sites they may want to visit and being redirected to sites they would not ordinarily visit.

And it's not just that adware vendors are criminals hiding in the dark reaches of the Internet. Many adware programs are unknowingly sponsored by the world's biggest Web sites (for example, Google, Nike, Yahoo, and so on) and adware venders are multi-million dollar companies getting millions of dollars of venture capital money. The adware vendor maintains just enough plausible deniability that it takes the legal authorities years to catch them. The legitimate companies that use the adware services don't realize they are dealing with adware vendors. They think they are dealing with a legitimate advertising firm (and many are).

There are many other types of malware, such as rootkits, which hide from forensic investigators, but most malware can be classified as one of the types just mentioned. It is also important to note that dedicated hackers often use automated malware to find their next victims. They let the automated program do the grunt work of the initial exploitation, which then contacts the hacker, who continues a more intelligent attack.


Where Windows Malware Hides

When hackers or malware accomplish the initial exploit into a computer, the next thing the hacker or malware does is to modify the system so that the maliciousness is hidden and so that they can always re-access the system at will.

To do this, the hacker or malware will modify Windows in one of five places:

  • Files

  • Folders

  • Registry keys

  • Applications

  • Other areas and tricks

I have documented over 145 different locations and tricks that malware and hackers will use to hide and re-gain system access. It is the most complete table of its kind. It contains nearly 100 registry keys that can be used maliciously, over 32 files, and over 14 folders. You can download the complete table at http://www.wiley.com/go/windowsvistasecurity. It is frequently updated. Table 2-1 shows some highlighted values pulled from the larger available table.

Table 2-1: Common Windows Locations Modified by Malware Open table as spreadsheet
NAME APPLICATION AREAS | FUNCTION
Archive files | Malware can be hidden or launched from within archive file formats.
Auto-run application files | Malware can launch from any auto-running file associated with a particular application.
Embedded or linked files | Many applications and their file formats allow other document types to be embedded/executed.
FILE AREAS
Alternate Data Streams | Malware can hide itself in the Alternate Data Streams (ADS) of a Windows file.
AUTORUN.INF | Autorun file, runs commands or programs referenced by open= or shellexecute= after inserting (or choosing to Autoplay) media storage (CD-ROM discs).
Desktop.ini | Used to customize folder behavior. It is meant to allow users to customize folder appearance and behaviors, but can be used to hide files and auto-launch programs when referred-to folders are viewed.
HOSTS | Used to place static DNS resolution entries.
Non-printable characters in file name | Several computer defense programs (for example, antivirus) are unable to scan files using un-printable or extended ASCII characters in the name.
Long path name trick or program.exe trick | If long path names with space in the name are not included in quotes, many programs, will attempt a systematic execution search that could lead to the wrong file (possibly malicious) being executed.
Internet shortcut trick to run local code. | Can be used to override HOSTS and DNS resolution
OLE2 document trick | OLE2-formatted documents will be opened in their correct associated application if no extension is chosen.
Protected file names (Lsass.exe, System, and so on) | Several program names, when running, cannot be killed in Task Manager, complicating removal.
FOLDERS
%Windir%\Start Menu\Programs\Startup | Default Startup folders; any program or command listed in one of these folders will be automatically executed when the user logs on.
Recycler | Recycle Bin's temporary storage location for deleted files and folders.
System, System32, %Windir% | Malware often writes itself to Windows system directories.
System Volume Information | Can be used by hackers or malware to hide malicious programs.
Tasks | Lists Task Scheduler Tasks.
Temporary Internet Files | Malicious files are often stored/hidden in Internet Explorer's Temporary Internet Files (TIF) folder.
OTHER
ActiveX control | Installed ActiveX control.
Defensively positioned dialog boxes | Malware often uses various programming "tricks" to cover up legitimate warning boxes or to trick the user into accepting a command that allows malware to enter the system when it otherwise shouldn't.
Executable pathway | PATH statement determines what paths OS should try if file is not found in default directory it was called from (i.e. Frog.exe vs. C:\Program Files\Frog.exe).
Hidden files | Hidden (or system) files/folders will not appear to casual searches.
Layered Service Provider (LSP) | Malware can insert itself as an LSP program, which can intercept any network traffic heading into and out of a PC.
Task Scheduler | Will run listed programs and commands.
Unusual folder/file names | Hackers and malware often use unusual names to hide malicious files and folders.
URL Monikers | URL Monikers can be added to Internet Explorer to load associated programs when a particular keyword is typed.
REGISTRY KEYS
HKLM\Software\Classes\<fileext>NeverShowExt | Real file extensions can be hidden.
HKCU\Software\Microsoft\Internet Explorer\SearchURL | Redirects any URLs typed in Internet Explorer to defined URL.
REGISTRY KEYS
HKLM\Software\Internet Explorer\Extensions | Adware/spyware can add buttons to IE that connect directly to malicious programs and scripts.
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\load | Runs commands or programs after user logs on.
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\run | Runs commands or programs after user logs on.
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell | Runs commands or programs after user logs on.
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\System | Runs programs after user logs on.
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Taskman | Runs programs in Task Manager after user logs on.
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run | Runs programs after user logs on, when Windows default shell (explorer.exe) runs for the first time during every logon.
HKLM\Software\Microsoft\Windows\CurrentVersion\Run | Runs programs or commands after user logs on.
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce | Runs programs or commands after user logs on for the first time only after the key is created.
HKLM\Software\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad | Runs commands or programs after user logs on, although typically points to the CLSID of the associated .DLL file. Links programs to explorer.exe process.
HKLM\Software\Classes\<filettype>\shell\open\command | Can be modified to run additional commands or programs when a particular file type is executed.
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL | Loads Windows logon user interface, loaded interface passes interactive user's logon credentials to Winlogon.exe.
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit | Specifies the programs that Winlogon runs when a user logs on.
REGISTRY KEYS
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects | Programs are loaded when Internet Explorer loads; programs loaded are also known as Add-Ins.
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler | Task scheduler programs that are launched when Windows starts.
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders | Determines location of Startup folders (i.e., Startup programs) and other common folders (for example, My Documents, My Favorites) for All Users profile.
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks | Contains the list of the COM objects, listed by GUID, that trap execute commands.
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx | Runs programs or commands after user logs on, in a controlled order. Runs listed value each time any user logs on until a user with admin permissions to registry key logs on; then it deletes the value after running.
HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices | Runs service after bootup prior to user logging on.
HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce | Runs service once after bootup prior to user logging on, and then deletes itself.
HKLM\System\CurrentControlSet\Control\SafeBoot | Used by Windows to determine what programs, services, and drivers are loaded in a Safe mode boot.
HKLM\System\CurrentControlSet\Control\Session Manager\Environment\PathExt | Determines what file extensions are tried if program name is typed in without an extension (i.e., Frog vs. Frog.exe).
HKLM\System\CurrentControlSet\Services | Will load program as service (i.e., prior to user being logged in).
HKLM\Software\Microsoft\Office\Outlook\Addins | Malware can add itself as an Outlook Add-in and manipulate incoming or outgoing e-mail.
REGISTRY KEYS
HKCU\Identities\<Identity>\Software\Microsoft\Outlook Express\<version>\Signatures | Malware can add a malicious script to Outlook Express e-mail signatures that retrieves malware automatically when opened by recipient.
HKLM\Software\Microsoft\Windows\CurrentVersion\URL\DefaultPrefix | Adds any string value as a prefix for any URL typed in the browser, effectively redirecting all typed in URLs to an unauthorized Web site first.
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DataBasePath | Can be used to point to a new, unauthorized HOSTS file instead of the HOSTS file in the normal location (i.e., \%SystemRoot%\Drivers\Etc).
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\ | Sets overall TCP/IP communications values including DHCP, DNS, and TCP/IP stack. These values are used unless a specific value is set under the \Interfaces subkeys on a particular interface.

Microsoft has worked hard to make most of these areas less vulnerable in Windows Vista. You can run many different utilities to determine if programs are launching from the areas listed in Table 2-1 or from the larger list of items listed in its parent table. Sysinternals' Autoruns (http://www.sysinternals.com/Utilities/Autoruns.html) is probably the best all around utility for listing and removing programs from these areas. Sysinternals was purchased by Microsoft in July 2006. Andrew Aronoff's Silentrunner.vbs script (http://www.silentrunners.org) can locate even more launching programs than Autoruns, but isn't as user friendly for removing them.


Why Malicious Hackers Hack

It begs the question: Why do malicious hackers hack? It used to be that hacking was for people to prove their hacking skills, and maybe brag to their hacker friends or to protest a corporate or political policy. In the past, intentional maliciousness and damage was the rarity, not the norm. Today, those types of hackers have been chased out by highly organized, distributed bands of professional criminals.

The primary intent of most malware and hackers today is for criminal gain. For that reason, many security experts now call malware crimeware. The name appropriately classifies the intent. Criminal hacking is so prevalent and widespread that it barely makes the newspaper. One-third of every adult American's identity was stolen in 2006 alone.

In the old days, if malware was found on someone's PC, an antivirus scanner was run, and the threat removed. Only the security paranoid recommended formatting the computer and starting all over. Today, that is precisely what all administrators should do. If hacking or malware is suspected on a computer, its legitimate data should be backed up (if not already), the hard drive(s) formatted, the OS installed and patched from knowingly clean media, and the data restored.

The compromised users should change all their passwords, not only on the local machine and network, but on remote resources as well (for example, Internet bank). The user should consider notifying their credit card companies and banks, and monitor their bank accounts and credit reports. The days of friendly and benevolent hackers are over. Today, hacking and malware are malicious and criminal.


Summary

This chapter discussed the major exploitation techniques and malware types. Hackers and malware generally use one of eight techniques for malicious exploitation: credential guessing/cracking, buffer overflows, OS or application vulnerability, OS or application misconfiguration, network eavesdropping, denial of service attack, client-side attack, or social engineering.

Dedicated attackers often use a step-by-step methodology to their malicious exploits. Typically, it begins by finding an active TCP/IP address; scanning for active, listening TCP and UDP ports; and then enumerating the particular services. The hacker then uses one of the eight penetration methods listed previously to break into the host. Then they copy the rest of their hacker tools, hide their presence, and make sure they can always get back in. Then they pillage and plunder looking information that can lead to additional compromises.

The major types of automated malware are: virus, worm, Trojan, bot, spyware, and adware. Most malware and hackers are now focused on crime, stealing identities, confidential information, and other types of professional maliciousness.

Chapter 3 covers Windows infrastructure, both on a host level and at a network and Active Directory level. It will show the reader how Windows really works, and identify the changes in those infrastructure technologies between Windows XP and Windows Vista.


Chapter 3: Windows Infrastructure

Understanding how Microsoft Windows functions, and Vista in particular, is key to understanding how to secure it. Most Windows administrators don't really understand how Windows "works." They've been taught about Windows from a system administrator's operational point of view, but not given enough information about how it operates under the hood. This chapter explains key Windows infrastructure processes and concepts so that the mechanics of how it all works together can be applied to security. This chapter will loosely flow along the lines of how a Windows PC boots and runs.

Note

Do not rely upon this chapter as the complete, detailed reference of the complexities of Windows Vista. Microsoft Windows is sufficiently complex that to cover any single concept completely would be beyond the intended scope of this book. This chapter is intended as a high-level guide. Readers who are truly interested in the internals of Windows will find a good resource in Microsoft Windows Internals, Fourth Edition by Mark E. Russinovich and David A. Solomon.

Boot Sequence

When the computer first turns on, hardware self-checks (called Power-on-Self Test or POST) are performed to ensure the hardware is functioning without error. Firmware located on flash memory, PROM, or EEPROM chips will contain either PC/AT legacy BIOS or newer Extended Firmware Interface (EFI) code.

EFI is an open standard invented by Intel (http://www.intel.com/technology/efi), but widely expected to replace the PC/AT BIOS code used in personal computers for nearly three decades, within the next few years. EFI requires new firmware, new drivers, and EFI-aware boot applications and operating systems.

The first release of 32-bit Windows Vista supports PC/AT BIOS firmware only, but has the "hooks" for the eventual EFI implementation. Microsoft plans to fully implement EFI in future 64-bit versions of Windows when the other vendor pieces are matured and widely available. There are currently no plans to support EFI in 32-bit versions of Windows. In the near future all computers should be 64-bit, so this should not be burdensome for long.

The boot sequence will be either EFI-based or legacy PC/AT BIOS-based, but not both. An operating system installed using EFI can only be accessed by booting with EFI, and vice versa. The firmware code is executed, along with any other ROM-or EFI-enabled hardware devices and interfaces cards (SCSI controller, video, and so on). See Figure 3-1 for a summary of the boot process, excluding any effects of BitLocker Volume Encryption.

Image from book
Figure 3-1: Windows Vista boot sequence summary

In the legacy scenario, the BIOS uses Interrupt 13h to find the computer's hard drive and then uses the disk system Master Boot Record (MBR) to locate the partition table. The partition table is used to locate the Windows bootstrap code on the disk containing the system partition. Vista's pre-boot code locates the Windows Boot Manager (Bootmgr), a hidden file in the root directory of the system partition. The Bootmgr file is the first piece of Windows to load. Everything before that is generic for any operating system.

In an EFI-enabled system, the EFI firmware loads EFI drivers and code, and locates the EFI system partition (ESP) using the new GUID partition table (GPT). The GPT replaces the legacy MBR and each disk is identified with a GUID, which allows EFI-enabled systems to support far more disks and more partitions per disk than the BIOS could.

Note

EFI systems require a minimum of two storage partitions, including the EFI System Partition, which is hidden from the OS.

In EFI-enabled systems, the Vista boot code locates the EFI Boot Manager (Bootmgr.efi) located under the hidden \Boot directory located off the root directory of the system partition (or in non-volatile random access memory (NVRAM) in the EFI firmware). This is intentionally made to be transparent, and most users will not be able to tell whether the NVRAM or the hidden \Boot directory is used.

Regardless of the two methods used, the Boot Manager then loads code supporting memory management, TPM, file systems, and PCI configurations, among other early loading components. Next, the Boot Configuration Data store file (called BCD located under the hidden \Boot folder) is called. The BCD replaces the legacy Boot.ini file. The Boot.ini file will be present only on dual-booting systems needing legacy OS support.

The BCD store's contents can be viewed and configured using the Bcdedit.exe utility. For administrators and security troubleshooters, it is important that managed systems be differentiated between EFI and legacy BIOS booting. When booting with diagnostic software, boot methods using the BIOS cannot access the BCD store located on the ESP, and vice versa.

In the \Boot folder there will be one or more Bcd.log (or Bcd.log X, where X is a sequential number) files. If boot logging is enabled, the Bootstat.dat file is updated with boot event messages. The Boot Manager then locates the Windows Vista boot volume and calls the Vista Boot Loader (Winload.exe located in \%Windir%\System32). Winload.exe replaces NTLDR (which will only be present on dual-boot legacy systems). The Boot Loader then loads the Vista OS kernel (Ntoskrnl.exe), which handles the rest of the Vista OS load.

Along the way, every step of the boot process is checked for authentication and integrity. The boot files' digital signatures are stored in a file called Nt5.cat, which is stored in \%Windir%\System32\Catroot\{GUID}. The {GUID} number can change as the OS is updated, but is named {750E6C3-38EE-11D1-85E5-00C04FC295EE} in the first Vista version released to the public.

Winload.exe is responsible for checking the integrity of boot drivers and the kernel is responsible for drivers loaded afterward.

Boot Viruses No Longer a Threat

Another big side effect of EFI-booting is that existing DOS-boot sector viruses are no longer a threat. Contrary to popular belief, 20-year old DOS boot sector viruses could easily disable all BIOS-reliant operating systems, including Windows XP Pro, Windows Server 2003, Linux, BSD, and OS X computers.

Once the OS is loaded, Windows XP Pro and Windows Server 2003 are in control and can't be infected or spread boot malware, but if a BIOS-enabled computer system is started with media containing a boot-enabled boot virus, MBR-infector, or partition table infector, it could still modify and "infect" the system. Incredible, but true. In most cases, the DOS-boot sector virus would just corrupt the system's boot sequence causing startup problems and crashes. Still, a single errant boot could keep the system down until the damage was repaired.

EFI-enabled systems do not have traditional boot sectors or partition tables to infect. Although bootable malware hasn't been much of threat in the last decade, EFI finally puts the nail in the coffin of old DOS boot viruses. New EFI boot viruses are possible, but would generally require booting from media created by an infected system.

BitLocker Volume Encryption

A common feared threat scenario is an attacker with physical access to a computer storing confidential information, say for example, with a stolen laptop. Boeing, the U.S. Veterans Administration (twice), the FBI (at least 317 times), the University of California, Allina Hospitals and Clinics, Fidelity, Chevron, Kaiser Permanente, the YMCA, QUALCOMM, and thousands of other organizations have all had laptops stolen, misplaced, or otherwise lost. In fact, the organization that knows where all the computer assets they have bought and paid for is rare, if it exists at all. The estimated cost of a stolen computer is $182 per customer record stored on it, according to one means of calculation by the Ponemon Institute (http://www.ponemon.org). You can probably easily imagine what would happen if a computer containing your organization's most sensitive secrets were purloined.

Once in the hands of the thief, logon security will not let the attacker into the operating system and any data protected by NTFS security without a valid logon name and password. However, the attacker can easily boot around the operating system and bypass the NTFS security restrictions. This is why one of the enduring truths about computer security is that if a bad guy has physical access to your computer, it ain't your computer any longer.

Knowledgeable attackers commonly use NTFS-aware versions of Linux or utilities such as Ntfsdos (http://www.sysinternals.com/Utilities/NtfsDos.html) to access otherwise protected NTFS volumes. Windows PE, which can fit on a USB drive or on a boot CD-ROM, can also be used to boot around the hosted Windows boot code.

By booting with these operating systems or utilities, it is possible to view files stored on NTFS-protected volumes without a password. Attackers can view and copy confidential data, and access the computer's local Security Accounts Manager (SAM) database to steal password hashes.

While confidential data can be protected with optional Encrypting File System (EFS), most Windows users don't take advantage of it; and even if they do, it is easy to put something in a folder where EFS is not used. Furthermore, EFS is only as secure as the password of the user who used EFS to protect the files. As that password is typically stored in some hashed form (either in the local SAM or as a cached credential) on the system itself, the attacker can usually circumvent EFS with not too much trouble. Finally, even if one assumes away the implementation issues with EFS, prior to Vista it was impossible to protect many types of files and folders (system Pagefile, system files, and so on) with EFS. Enter Microsoft BitLocker Drive Encryption.

BitLocker allows Vista (or later) volumes to be encrypted to prevent boot around attacks. By default, BitLocker can encrypt the boot volume (the volume where Windows system files and data are normally stored), but additional volumes can also be encrypted. BitLocker can protect the disk volume until the user supplies a PIN or supplies a key stored on a USB flash memory drive.

Note

Although it sounds confusing at first, the system partition is the drive volume where the boot code is located, and the boot volume is where the Windows system files are stored. BitLocker protects the latter by default.

The cryptographic key that is involved with the data encryption/decryption is called the Full Volume Encryption Key (FVEK). It is encrypted by another BitLocker encryption/decryption key called the Volume Master Key (VMK) and stored on the local volume. There is a different VMK for each encrypted volume. This parent-child arrangement allows stronger encryption to be implemented with fast performance. BitLocker further encrypts the VMK and stores it, in encrypted form, on the local volume as well. The encryption/decryption key that is used to protect the VMK can be stored on the local hard drive, protected by an external key (provided by the user or located on a USB drive), or stored on a specialized cryptographic microcontroller chip.

Note

Contrary to frequently published documentation, BitLocker does not encrypt the entire boot volume. Key parts of the boot volume, necessary for BitLocker's operations (e.g. boot sector, volume metadata, encrypted FVEK, encrypted VMK, etc.), plus any sectors marked as bad, are not encrypted.

BitLocker, in its recommended state, can encrypt the VMK with another key (called the Storage Root Key) stored on a cryptographic chip called the Trusted Platform Module (or TPM). TPM is an open standard created by the Trusted Computing Group (http://www.trustedcomputinggroup.org) and widely endorsed by hardware and software vendors including Microsoft and several Linux distributors. The TPM chip (see http://www.en.wikipedia.org/wiki/Trusted_Platform_Module for more generic details) can be used for nearly any cryptographic process, and not just BitLocker. But it is Vista and BitLocker that will bring TPM to the masses.

BitLocker requires Vista (only Enterprise or Ultimate editions support Bit-Locker), an enabled TPM chip (version 1.2 or later), a TPM-enabled mother-board, a TPM-enabled BIOS, and two NTFS-formatted drive partitions. Most popular computer vendors are currently shipping the majority of their systems TPM-ready. The two drive partitions must exist before installing Vista or can be created afterward using a non-destructive disk partitioning utility. Microsoft provides one called the BitLocker Drive Preparation Tool (http://www.support.microsoft.com/kb/930063). Microsoft recommends a 1.5GB system partition for BitLocker to reside upon. BitLocker protects the boot volume, not the system partition (the partition the computer boots on). Thus, any files or information on the system partition can be read by an offline attack.

However, the data protected by BitLocker on the boot volume will be encrypted until the correct decryption key to unlock the VMK (which unlocks the FVEK) is supplied. The decryption key can be stored on the local hard drive (not providing too much additional protection), or on the TPM chip. Additionally, the administrator can require that a 4-to 20-character PIN or key stored on a USB drive be presented in order for BitLocker to decrypt the boot volume. BitLocker uses 128-bit Advanced Encryption Standard (AES) ciphers by default, although administrators can choose stronger keys.

Note

Users should not save confidential files to the system partition because BitLocker protects files on the boot volume only.

If the hardware requirements are already in place, TPM must be enabled first, followed by BitLocker. BitLocker requires the same boot process each time the system boots. BitLocker provides the volume encryption while the TPM chip stores the decryption key and verifies the integrity of the boot up process. TPM compares the integrity of the BIOS (if present), optional ROMs, boot sector, boot loader, and Boot Manager against previously stored values. If any of them have been modified, BitLocker halts the boot process and prompts the user for a recovery method. BitLocker requires the same boot process each time the system boots, and thus a hard drive moved between two systems, or between a BIOS-and an EFI-enabled system, will not be easily accessible without a successful recovery method.

Note

Many customers may want to consider disabling BitLocker's integrity checking of BIOS and ROM, if it is not already disabled. Firmware updates to any of these would cause BitLocker to prevent booting without requesting a recovery method. Even new USB drives present at boot could cause a boot failure.

If BitLocker refuses to boot, the user can supply a previously defined recovery password (48-characters) or 128-bit recovery key. The recovery password can be printed when BitLocker is enabled, saved onto a network folder or other drive location, or stored on a USB flash memory drive. Active Directory has been extended so that BitLocker recovery passwords (and keys) can be archived into Active Directory for recovery purposes. Longhorn server and new Active Directory forests will have the necessary schema attributes and will not require the customer to extend the schema separately.

Don't confuse the keys that have to be provided by the end user when using BitLocker. There can be two manually provided keys: the Boot-up key to unseal protected volume(s) during normal operation and the Recovery key. The Boot-up key can be:

  • Optional: Can be configured to not be required

  • PIN (provided by user)

  • Startup Key (stored on a USB drive)

  • Protected by the TPM chip

  • The Recovery key, used if the BitLocker boot sequence fails for any reason can be:

  • Recovery key (provided physically)

  • Recovery password (manually inputted)

  • Both, you can use either one separately

Enabling TPM and BitLocker

Once you decide to turn on BitLocker Drive Encryption, the summarized steps are:

  1. Decide on BitLocker Boot-up key mode

  2. Choose and prepare for Recovery method

  3. Enable TPM hardware in BIOS, if used

  4. Initialize TPM in Vista, if used

  5. Enable BitLocker

  6. Validate BitLocker Configuration and Installation

Assuming you have and want to use TPM, the TPM chip must first be initialized (or when you attempt to initialize BitLocker for the first time, it will prompt you to enable the TPM functionality before proceeding anyway). The TPM chip functionality can be accessed using the new TPM Microsoft Management Console, Tpm.msc (see Figure 3-2).

Image from book
Figure 3-2: New Trusted Platform Module (TPM) console

Choosing to initialize the TPM chip will result in the dialog box presented in Figure 3-3, and requires a reboot. During the startup, a text-based screen from the BIOS will inform you that the TPM is about to be modified and will ask the user to either ignore or to allow the modification. This screen may show up twice.

Image from book
Figure 3-3: Initializing the Trusted Platform Module (TPM) chip

Next, as Figure 3-4 shows, you are asked to create a TPM management password. You can manually create one or allow TPM to create one. As this password is meant to be stored on a flash memory drive or printed anyway, we recommend letting the wizard create it for you. It will create a very long, random password.

Image from book
Figure 3-4: Creating a Trusted Platform Module (TPM) password

You can print the password or save to another location including a USB flash memory drive (see Figure 3-5). We strongly recommend saving or printing the password, which should then be stored in a secure place. You will need it later if you have to recover this system's data.

Image from book
Figure 3-5: Saving the TPM password to media

Only after the TPM management password has been saved will TPM finish initializing (see Figure 3-6). Finally, you'll be greeted with a TPM initialization completed message.

Image from book
Figure 3-6: TPM initialization in process

There are several options for customizing TPM and BitLocker's behavior. To access, use group policy or local computer policy (Gpedit.msc) and choose the following leaf container (see Figure 3-7) , Computer Settings\Administrative Settings\BitLocker Drive Encryption.

Image from book
Figure 3-7: TPM and BitLocker group policy settings

By modifying the "Configure TPM platform validation profile" setting you can modify the validation that the TPM does each time the computer is started. Note that some of these options can cause severe problems. For instance, if you enable the option to validate the BIOS, you will be unable to flash a new BIOS on the system without first turning off BitLocker and the TPM. This obviously increases security, but at the expense of a significant amount of usability.

Next, access the BitLocker Drive Encryption applet under Control Panel (see Figure 3-8).

Image from book
Figure 3-8: Enabling BitLocker using the BitLocker Drive Encryption applet

Figure 3-9 shows the various BitLocker startup options. They include providing no additional key during startup, manually supplying the 48-character PIN, or supplying a 128-bit key from a USB flash memory drive. We highly recommend using BitLocker with at least one additional authentication factor, assuming your users will put up with it. It definitely increases your security. Figure 3-10 shows the USB key option being selected.

Image from book
Figure 3-9: BitLocker startup options
Image from book
Figure 3-10: Saving BitLocker key to USB

Next, the user is prompted for how to store the recovery key in case Bit-Locker prevents booting. Figure 3-11 shows the various options. The recovery key is used only if BitLocker fails to boot using the normal key for some reason. This could happen because the hardware in the computer changed, or because of some failure condition. The recovery key is also needed to boot into the recovery console. We recommend making an electronic copy of the recovery key on a USB flash memory drive and also printing it for redundancy. You can never really have too many backups of these things. You should store both items in a secure location. If you are truly paranoid, you can make as many copies as you wish, and store them in several locations. Just be sure to keep track of where they are. You can store several recovery keys on a single USB flash memory drive. The computer will sort out which one belongs to which computer when it needs them.

Image from book
Figure 3-11: Saving a BitLocker recovery key

As Figure 3-12 shows, Windows Vista encourages one last final check of recovery and encryption keys before BitLocker encrypts the boot volume. This check is heavily recommended and should not be bypassed. It simply involves booting using the newly created BitLocker settings, including any additional authentication factors you elected to use. If you do bypass this check and your system does not recognize your USB token at boot time, you will need to enter the recovery password (40 digits) to restart the system. As soon as the system boots successfully, the actual encryption of the volume will start.

Image from book
Figure 3-12: Enabling BitLocker system check

Upon reboot and logon, you will see a balloon message similar to Figure 3-13.

Image from book
Figure 3-13: Initial BitLocker encryption in process

During the encryption process you may notice that the volume you are encrypting is shown as full and with a red bar in Windows Explorer. This is by design. Windows will automatically use as much of that volume as it can during the encryption process to speed up the operation. Eventually, the boot volume will be fully encrypted and protected (see Figure 3-14).

Image from book
Figure 3-14: Confirming BitLocker encryption status in disk management

BitLocker Drive Encryption provides solid boot volume encryption with several startup and recovery methods. When used with a TPM chip, it is a very secure technology. Several analysts have suggested that stolen computer assets with Vista-enabled BitLocker do not have to be reported as compromised as often mandated by public privacy disclosure laws.

Note

If there is no external keying material, and only TPM is used, thieves can boot your OS and can then attack it through any external-facing port, service, or application (as covered in Chapter 2).


Post-Boot Startup

After Windows Vista boots, additional drivers, services, registry entries, and other "autorun" programs are loaded. The networking components are loaded. Initially, a smaller, temporary, network stack is loaded, enough so that Windows can initiate a DHCP request (if enabled), and use a few other basic services (such as DNS to locate other core network services and hosts). During this phase, inbound network traffic is limited to a few essential services. This is to prevent malware from attacking Windows Vista before Windows Firewall and IPsec are loaded. The Network Location Awareness service is used to identify any network topology changes, like a mobile laptop needing a new DHCP-provided IP address because it is connecting to a new network. Eventually Windows Firewall is fully loaded, and the temporary network stack is replaced with a permanent version.

Applying Security Policy

During this time, Windows also loads any predefined computer security policies. When the computer first boots, the PC's computer-centric Local Security Policy (gpedit.msc) settings are loaded, if there are any values. These settings apply to the computer itself, and consequently, all users of the computer.

If the computer is joined to a domain, the computer will log on to a domain controller and provide its computer account password. After authenticating, a secure SMB channel is established between the computer and the domain controller. Any computer-specific domain group policy objects, or GPOs, (covered in more detail in Chapter 14) are then applied in the following order: site-level, domain-level, and then any organizational unit-(OU-) level GPOs.

When a user logs on to the computer, user-specific Local Security Policy settings are applied, if any. After the user authenticates to the domain, user-specific GPO settings are applied, following a similar order as used for computer-specific policies. Figure 3-15 summarizes the Local Security Policy and GPO-application order.

Image from book
Figure 3-15: Local Security Policy and GPO application order

Name Resolution

Windows uses both DNS and NetBIOS name resolution. During the startup process and ongoing operations, Windows is constantly performing name-to-IP address resolution. Contrary to popular belief, it isn't all DNS. The Domain Name System (DNS) service resolves DNS client queries converting DNS names to IP addresses. Windows uses DNS to resolve Internet name queries, and also for queries looking for DNS registered hosts and Active Directory services.

For example, DNS is used when Windows is booting to find a domain controller for the computer to log on. The NetLogon service sends DNS queries to the primary DNS server looking for Service Resource (SRV) records. SRV DNS records indicate which IP host is a domain controller, global catalog server, and so on. When a domain controller's IP address is found, the workstation will then connect to the domain controller's LDAP service on port 389 to enumerate other important information.

Most DNS client queries follow a set path (as shown in Figure 3-16). When a client needs to resolve a DNS name to an IP address (say for Internet browsing, for example), the DNS client service (called the DNS resolver in DNS technical circles) will first check the local DNS cache. The DNS cache is an area in memory that stores just resolved DNS names. If Windows has recently (within minutes) resolved a particular DNS name, it can quickly pull the resolution information out of the cache, and not have to perform a full DNS query.

Image from book
Figure 3-16: DNS query order

If the DNS answer is not in the local cache, the DNS client will then check the computer's local HOSTS file. The HOSTS file contains static DNS resolution entries. In Windows NT-class computers, the HOSTS file is located in \%Windir%\System32\Drivers\Etc. It can be modified by administrators only.

Be aware, however, that if an administrator adds entries to the HOSTS file, Windows Defender, the built-in anti-spyware tool in Windows Vista, will flag it as a potential intrusion. Modifying the HOSTS file is a favorite trick of spyware to make users go to Web sites other than the ones they intended to go to.

If the HOSTS file does not resolve the DNS query, the DNS client sends a resolution request to the first DNS server located in its TCP/IP properties tab (or as provided by DHCP). The DNS server then takes it upon itself to resolve the query, or forwards the request to another server. Either way, the DNS server normally sends the answer to the DNS query to the DNS client, which then passes it along to the original requesting application.

NetBIOS Name Resolution Is Often Required

DNS as a primary name resolution service (outside of Internet queries only) was first introduced in Windows 2000. Prior to Windows 2000, Windows almost always used NetBIOS name resolution to find private host addresses and services. NetBIOS name resolution can be accomplished using a broadcasted NetBIOS name resolution query or by sending a query request to a participating Windows Name Service (WINS) service or WINS proxy.

Many administrators mistakenly believe that NetBIOS name resolution no longer occurs or believe that WINS is no longer needed on today's Windows networks. This is not always true. Windows frequently uses NetBIOS name resolution as its first and primary name resolving method. All Windows computers require a NetBIOS name, and Active Directory cannot even be installed on a file server without giving the Active Directory domain a NetBIOS name.

Frequently, Windows will look for a given resource using its NetBIOS host name first, and if not found, fall back to DNS. Other times, older versions of Windows and legacy applications, will only use NetBIOS name resolution. NetBIOS name resolution follows a path similar to DNS client resolution, but instead uses a HOST file replacement called LMHOST, and WINS servers instead of DNS servers (if WINS is enabled). In most enterprise scenarios, if the PC cannot reach a WINS server, it then falls back and sends a broadcast query (called hybrid mode). Understanding the potential requirement for Net-BIOS name resolution is important to the security administrator.

User Profiles

When a user successfully logs on, his user profile is loaded. A user profile normally contains the user's customized desktop settings, background picture selection, and many application settings (for Internet Explorer, Outlook, and so on). If a user uses EFS or has PKI digital certificates, they are often stored in their profile. A user's Document's directory can also be stored there, although it tends to slow down logons and logoffs as the directory grows larger.

Profiles can be stored locally, or stored on a referenced Windows network drive. Network profiles are also known as roaming profiles, because they can be applied to every PC the user logs on to. If the profile is stored on the network, when the user logs in the user's roaming profile will be copied down to the local hard drive and be applied to the computer. When the user logs off, the user's profile will be copied back up to the network drive. By default the user's network profile will be left on the local drive, but you can configure Windows to delete the local profile to increase security.

Actually, the process is a bit more complicated than what we've already discussed. Any new user's profile is created using the Default User profile from the first computer the user logs onto. It is the template from which all other profiles on the local computer are made.

Before the user's personal profile is applied during a logon event, Windows applies the All User profile. Whatever settings are in this shared profile are applied to the computer first and merged into all the logged on users of the computer. The user's personal profile then overlays the All Users profile, and any conflicts are usually won by the user's profile (unless a mandatory shared profile is enforced).

Prior to Vista, the All Users profile was stored in \Documents and Settings\ All Users folder. In Vista, the All Users profile is stored in \Users\Public. Administrators have Full Control to the Public folder. For backward compatibility with legacy applications, Windows has several symbolic links that end pointing to \Users\Public. First, the symbolic link \Documents and Settings, points to \Users. The \Users\All Users profile points to \ProgramData, but in a confusing mix, \ProgramData and its subdirectories point to \Users\Public. Table 3-1 lists some of the related symbolic links.

Table 3.1: Vista Symbolic Links Open table as spreadsheet
FOLDER\SYMBOLIC LINK | REDIRECTS TO
\Documents and Settings | \Users
\Documents and Settings\All Users | \Users\Public
\ProgramData\Desktop | \Users\Public\Desktop
\ProgramData\Documents | \Users\Public\Documents
\ProgramData\Favorites | \Users\Public\Favorites
\ProgramData\Start Menu | \ProgramData\Microsoft\Windows\Start Menu
\ProgramData\Templates | \ProgramData\Microsoft\Windows\Templates

The end result of all the interaction between the Default User, the All Users, and personal user profiles (networked or local) is that malicious code has many places to hide, and more places to search for passwords and private encryption keys, if it was successful in exploiting Windows. A conscientious forensic explorer needs to be aware of how profiles interact and where things are stored.

Services

Windows Vista comes pre-installed with over 130 different services, depending on the features installed and activated. Over 75 services are turned on by default, and new software can be installed to create more. Administrators often wonder how a service is different than a regular application.

Services can be activated and executed by Windows when it starts up without needing to have a user logged on. Each service logs on the local computer (or network) and runs in a predefined user account context. Most services run in the Local System (or System) security context. This account is the most powerful account in Windows. If an attacker buffer overflows a service running in the System context, the attacker may gain System privileges and permissions and completely control the system. The reason this is a "may" and not a "will" is that, in Windows Vista, even services that run as LocalSystem are restricted in certain ways. We will discuss this-it's called service hardening-in Chapter 6.

Windows attempts to limit the widespread effectiveness of buffer overflow, and other privilege escalation attacks, by installing (and allowing) services to run in many logon service contexts beside System. Microsoft provides the less privileged Local Service and Network Service service accounts for services needing limited access to the local system and/or network.

The Local Service account has permissions and privileges similar to an authenticated user on the local machine, but accesses network resources as the anonymous null session user. The Network Service account accesses local resources as if it were a member of the Authenticated Users group (like the Local Service account), but accesses network resources with the credentials of the local computer account (which is always more than the anonymous null session account).

If any of the three default service accounts are used with a service, the administrator does not need to choose or enter a password. Windows chooses long and complex passwords automatically for these accounts and changes them on a regular basis. Accordingly, because there is no known password, it is difficult to log on to a Windows computer using these service accounts.

Any user or computer account can be used as a service account, but it must be assigned the Logon as a Service right. This right allows the service to interact with the Service Control Manager (SCM) and allows the service to start without waiting for an interactive user to logon. If a custom service account (i.e., not Local System, Local Service, or Network Service) is used, a valid logon name and password must be provided. The service account password is then stored locally on the computer in protected form. Windows Vista protects service account passwords more than prior versions of Windows. In previous versions, a local attacker with administrative privileges could run a malicious utility and extract service account logon names and passwords. Windows Vista disables those current attack tools.

Windows Vista does much more than previous versions of Windows to limit attacks against default services. Each service was reviewed to remove potential buffer overflows. If a service is interrupted by a malicious program, the service has a better chance at self-recovering, or if it cannot ward off the attack, shutting down or restarting.

Microsoft reviewed each default service's needed permissions and assigned the least privilege permissions needed to do the job. The SCM does a quick run time privilege review on services getting ready to start, and removes all unnecessary privileges and permissions from the service during the start process. Many services are assigned the Restricted token, which significantly limits what other objects the service can access, and many others are marked as write-restricted (meaning they cannot modify other Windows resources). Services can also be network restricted using Windows Firewall and IPsec. The idea is that if the service does get successfully attacked, the service is less likely to allow full system access.

One last final caution when configuring new services: Each service running in the Local System context can be enabled to allow the service to interact with the desktop (see Figure 3-17).

Image from book
Figure 3-17: Example of allowing a service to interact with the desktop

This is required for services that must interact directly with a logged in user. Any information an enabled service displays on the desktop, will appear on the interactive user's desktop too. This could reveal sensitive information or allow the logged on local user to manipulate the service to gain higher privileges.

Windows Vista allows (as XP Pro does as well) programs and commands to be run when services fail. This feature can be used to send an e-mail or network message to the Help Desk or administrator to warn of an anomaly. In Figure 3-18, the open source SMTP program Blat (http://www.sourceforge.net/projects/blat) is being used to send an e-mail message along with the number of times the service failed.

Image from book
Figure 3-18: Example of a service sending a message after it fails more than two times


Services You Need To Understand

While it is important that a Windows administrator understand every service that is running on the computers they manage, the following services are essential to Windows, and at the same time often inadequately understood.

Svchost

Svchost stands for Service Host Process. Svchost is essentially a "wrap-around" service shell that other DLLs can use to execute as a service, and to communicate intra-and inter-computer. Svchost is used for services that are implemented as DLLs instead of as their own executables. This allows related services to communicate with each other much more easily. However, you must remember that all services within a single Svchost process have complete control over all other services within that same process. In other words, you must not put two services that inherently have different security requirements in the same Svchost instance.

Most Windows computers have several instances of Svchost running, and each instance normally hosts one or more services. Svchost.exe always executes from %Windir%\System32. If you find Svchost anywhere else, it's malware. You can list the various programs that are running with each instance of Svchost by running Tasklist /svc at the command prompt (see Figure 3-19). You can also display a similar list in Windows Defender. One of the most crucial Svchost processes is RPC.

Image from book
Figure 3-19: Tasklist /svc revealing svchost hosted processes

RPC

RPC stands for Remote Procedure Call. RPC is a common protocol in Windows, Linux, and other operating systems, for programs and services to communicate with each other. Although it most commonly is used over TCP/IP networks, it will work over any transport protocol. Dozens of Windows programs use RPC to communicate, both intra-computer (i.e., different programs on the same computer will use RPC to send information to each other) and inter-computer (for example, client-server). There are also protocols written on top of RPC, like the Distributed Component Object Model (DCOM).

The RPC Endpoint Mapper (called Remote Procedure Call in the services console) service runs on port 135 in Windows (an equivalent service runs on port 111 in Linux/Unix). When an RPC-enabled program starts, it will contact the RPC Endpoint Mapper service and ask for an available, open TCP port to listen on. The RPC service will query the currently open TCP ports and pick one of the unused (and not likely to be used by any other well-known program) TCP ports above 1023 and inform the program. When a client of this program needs to communicate with it, the client will query the RPC Endpoint Mapper to find out which port the program listens on. It can then connect directly to that port. In a way, the Endpoint Mapper functions as a directory service for certain ports on a host. For example, Outlook normally uses RPC to talk to Exchange in a local network environment. When Exchange wants to talk to a particular Outlook client, for instance, to notify the client that it has new e-mail messages, Exchange will query the client computer's RPC service on 135. The RPC Endpoint Mapper service will tell Exchange what port Outlook is listening on. Exchange will then disconnect from the RPC service and re-connect directly to the Outlook client.

RPC is how Windows works and is used for inter-process communications locally as well as remotely. It's crucial to normal operations. Disabling RPC will severely hamper or disable many core Windows services, including:

  • Exchange

  • Outlook

  • File Replication Service

  • Active Directory Replication

  • DCOM Programs

  • IPsec

  • WLAN AutoConfig

  • DHCP Client

  • DNS Client

  • Protected Storage

  • Performance Monitor

  • Server

  • Workstation

  • Certificate Services

  • Windows Firewall

  • Local Security Authority sub-system (i.e., Lsass.exe)

From the preceding list, it's easy to see that RPC can't be disabled lightly as some security guides suggest. When the MS-Blaster worm came out in August 2003, it attacked unpatched Windows computers over DCOM, which in turn used the RPC service as its transport. Early on several antivirus companies recommended that administrators disable the RPC service to stop the worm. Talk about the medicine being worse than the illness. Disabling RPC essentially disables most of Windows.

SMB/CIFS

Windows is heavily dependent on the Server Message Block (SMB) protocol for exchanging files and other information. Windows' first implementation of the SMB protocol was transported over another protocol called NetBEUI (Network Basic End User Interface). SMB over NetBEUI relies heavily on NetBIOS name resolution.

Once NetBIOS was improved so that it could be transported using TCP/IP, and expanded beyond a single network segment (as NetBEUI was limited to), it was renamed as Common Internet File System (CIFS). Throughout this chapter, when the term NetBIOS was used, CIFS would have been more technically accurate.

CIFS uses the TCP/IP protocol and can use both DNS and NetBIOS name resolution. By default, CIFS uses UDP and TCP ports 137 (for name resolution), 138 (for datagram traffic), and 139 and 445 (for session-oriented traffic). Typically, 137 and 138 are UDP ports, while 139 is TCP, and 445 can be either. SMB over native TCP/IP uses port 445. It was available in Windows 2000 and later. Other services will attempt to use 445 first, and then fall back to the earlier ports if unsuccessful over 445. Ports 137–139 are used for legacy applications.

SMB's most frequently recognized use is for File and Printer sharing, a service that allows folder, registry, and printer shares to be advertised and used remotely. Many administrators incorrectly think that SMB is used only for File and Printer sharing. Many security recommendation guides have recommended that administrators block the SMB ports using a host-based firewall if File and Printer sharing was not needed. This is usually bad advice, unless you know what you are doing. Like RPC, SMB is used extensively during normal operations, and for many other things besides sharing folders and printers, especially for remote management.

SMB connections are normally made to a computer's IPC$ (Interprocess Communication Share). Various services will open Named Pipes connections. Named Pipes can be best thought of as File and Printer sharing for applications and processes. An SMB-enabled application will open up an SMB share point, with names formatted to look something like a NetBIOS share name (for example, \\servername\\pipe\servicesharename). These pipes can be accessed by clients and used as regular files to read and write data to the server. Some example Named Pipes share names are:

     \\fileserver\\keysvc
     \\PIPE\wkssvc

You can run the Microsoft Windows Server 2003 Resource Kit utility, Rpcdump.exe, to see some of the Named Pipes on a particular system. Services and processes use Named Pipes to send and read information, much like a user implementing a drive share.

SMB excels at distributed file locking and read and write caching to improve performance. It is used by many other OS venders and applications besides Microsoft. It can be used intra-computer or inter-computer. It supports anonymous "null sessions" and authenticated connections. SMB is made for client-server communications.

Accordingly, SMB is often used by Windows services and other third-party products. SMB is used to establish a secure channel between a domain computer and a domain controller so the computer can perform a network logon. SMB is used for remote management and to pull group policy settings from the domain controller to the local computer. Like RPC, disabling SMB or blocking those ports on a normal Windows PC is bound to cause operational problems. The three services that use SMB the most are the Computer Browser, Workstation, and Server services.

Computer Browser, Workstation, and Server Service

The Computer Browser service is used to advertise and find NetBIOS hosts and services. It is included in XP Pro and later only for computers that do not use Active Directory, or to find NetBIOS objects that do not register themselves in Active Directory. Prior to Active Directory, it was the primary way that Windows found computers, workgroups, and domains. In Vista, the Computer Browser service is an Automatic service, but may not be started. Windows starts the service when needed. Vista will try using Active Directory searches first for domain computers.

The Workstation and Server services have nothing to do with whether a PC is running a workstation or server version of Windows. Both workstation and server versions of Windows run both by default. All Windows computers have services that listen and allow connections from other hosts (using the Server service), and connect to other hosts (using the Workstation service).

The Workstation and Server services are a little bit like Svchost, RPC, and SMB in that lots of other services and applications use them to do their job. The Workstation service is used when the computer wants to use outbound SMB to connect to a (remote) listening SMB share (hosted by the Server service). The Server service is used to create inbound listening shares. The Workstation service of one client will often connect to the Server service of another.

Both the Workstation and Server services use SMB and RPC, and have been the victim of past exploits. Many security recommendation guides often recommend that Windows administrators disable these services if not needed. Like RPC, it's difficult to disable either service as Windows is very dependent upon them. If you disable the Workstation service, many applications and services will not work correctly, including:

  • File and Print Sharing (trying to connect to shares on other computers, or host them locally)

  • Group Policy (on domain controllers, clients with the Server service will still download group policies)

  • Net Logon (would not be able to log on to this computer)

  • Print Spooler

  • Computer Browser

  • Connecting to any application that uses SMB

  • Connecting to any application that uses Named Pipes

  • Remote management interfaces

  • Distributed File System (DFS)

  • Remote Procedure Call Locator

  • Fax service

  • Indexing service

  • Performance Logs and Alerts

Disabling the Server service will affect many services including:

  • File and Print Sharing (allowing others to connect to folder or print shares)

  • Group Policy (sending group policy from a domain controller)

  • Net Logon (allowing other remote computers/users to logon)

  • Allowing connections to any application that uses CIFS

  • Allowing connections to any application that uses Named Pipes (SQL Server, Certificate Services, Exchange, and so on)

If it is an RPC-enabled service (and doesn't use Named Pipes or some other transport method), there is a good chance that disabling the Server service will disable connections to the service.

It is important to understand the function of all these specialized programs and services, and what they provide to Windows. Disabling any of the services discussed will cause operational problems on most PCs and should only be done on production systems after testing application functionality and only then if there is a valid and unacceptable threat facing these computers.

Autorun Programs

After Windows boots and the core services are loaded, Windows checks many other areas for program files that have been marked to execute after each boot. There are literally over a 100 places that a program can be placed to be autorun after the computer re-starts. These locations include:

  • Registry keys

  • Startup folders

  • Files

Without a doubt, most autorun programs are executed by placing startup entries in the Windows Registry. The most common registry autorun key is HKLM\Software\Microsoft\Windows\CurrentVersion\Run.

The most common startup folder is \Users\%Userprofile\StartMenu\ Programs\Startup. Any program located in the Startup folder would be automatically executed when the user logged on. Although autorun files are not commonly used anymore, the following files will autorun programs if they contain information and are run in a 16-bit subsystem: Autoexec.nt and Config.nt.

Autorun locations are important because both legitimate and malicious programs often like to launch themselves using one of the autorun methods. Microsoft has virtualized many of the most commonly used locations in Vista so that legacy program or malicious modifications do not lead to full system compromise. You can view most of the autorun programs and their launch points using Microsoft's excellent Autoruns utility (http://www.microsoft.com/technet/sysinternals/Security/Autoruns.mspx) as shown in Figure 3-20.

Image from book
Figure 3-20: Example of Autoruns utility


Registry

The Windows Registry (i.e., the Registry) is a hierarchical local database for storing system and application settings and parameters. If you are used to Unix/Linux, you can think of it as a central, gigantic place to logically store all the data normally contained in all the .conf files related to each application or daemon.

Registry Structure

The Registry is divided into five different major sections, called hives or subtrees. The five hives, as shown in Figure 3-21, are HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS, and HKEY_CURRENT_CONFIG. They are often abbreviated as HKCR, HKCU, HKLM, HKU, and HKCC by authors, including in this book. You can explore the Registry (and view, search, modify, and delete information) using Regedit.exe.

Image from book
Figure 3-21: Main Registry hives

Under each hive are keys, subkeys, values, and data-making up thousands of separate database entries. Keys are the first level under the subtrees, followed by the lower subkeys, the subkey values, and the data of each value. Keys and subkeys can contain values, each of which would typically have a name and a piece of data associated with it. There can be one or more values under each subkey. Each value can contain data of only one format. Probably the most common format is REG_DWORD, actually, a REG_DWORD32 on a 32-bit computer and either a REG_DWORD32 or REG_DWORD64 on a 64-bit computer. A REG_DWORD is a 32-or 64-bit binary value interpreted as a binary bitmask or as a decimal or hexadecimal integer. Other common formats are REG_SZ (a single string) and REG_MULTI_SZ (several strings separated by carriage-return+line-feed characters). In the Figure 3-22, the hive is HKLM, the key is \Software, the subkey is \Microsoft\Windows\CurrentVersion\ Run, the value is Windows Defender, and the data is %Program Files%\Windows Defender\MSASCui.exe-hide, which in this case is the registry key that causes Windows Defender to launch at user logon.

Image from book
Figure 3-22: Example HKLM\Software\Microsoft\Windows\CurrentVersion\Run

HKey_Local_Machine Hive

HKLM is one of the most important hives to understand. Actually, all of HKLM is virtual and composed of pieces from elsewhere. It does not exist when the system is not running. The HKLM hive stores configuration information for hardware and software of the computer regardless of who is logged on. It contains seven keys: BCD00000000, Components, Hardware, SAM, Security, Software, and System.

The BCD00000000 holds the EFI boot values and can be viewed only with elevated permissions. The Components key, introduced in Vista, is the location where applications, COM, and DCOM objects should be registered.

The Hardware key contains information about the physical hardware of the computer. The key HKLM\HARDWARE is not stored as a file, because it is recreated each time the system starts. Any values created during the Windows session are discarded when Windows is shut down. Hardware information about local devices, interrupts, and hardware configuration information are stored under this key. You can view a lot of this information by using the Device Manager applet under the Control Panel. Windows and other applications can access this key to interface with the hardware appropriately.

The SAM key is the SAM database that stores authentication and security information about the different security principals (user, group, computers, and so on). It is usually protected from direct manipulation, even by the administrator. Occasionally, various malicious hacking tools are able to access it and extract password hashes, but Microsoft always seems to patch Windows and close the holes.

The Security key contains stored secrets, values, and security configuration information that is accessible only to the System account by default.

HKLM\Software is the most popular Windows key by legitimate users and malware. \Software contains registration and configuration information for the operating system and application software installed on the local machine. It contains many of the registry autorun keys (including the most popular autorun key, HKLM\Software\Microsoft\Windows\CurrentVersion\Run). It contains subkeys for nearly every installed software program.

HKLM\System is second in malware popularity only to HKLM\Software. It contains operating system information that controls system startup behavior, device drive loading, service configuration and loading, and overall OS operations. An example is HKLM\System\CurrentControlSet\Control\Safeboot\ Minimal. This subkey controls what services are loaded if the OS is booted in Safe mode.

Many forensic investigators rely on Safe mode to remove any malware programs when searching for signs of infection and maliciousness. Many malware programs manipulate this key so that they are loaded, and can thus manipulate or hamper forensic techniques even when the OS is in Safe mode.

All 64-bit versions of Windows store many HKLM\Software pre-64 bit registry keys (i.e. 32-bit) under a single location in the registry, HKLM\Software\ WOW6432Node. 32-bit programs accessing HKLM\Software are seamlessly re-directed to the new location. If legacy malware (pre-Vista) is exploiting Windows, chances are high that it will load itself using a subkey located under HKLM.

HKey_Classes_Root

HKCR is most commonly used to list the effective Windows file associations linking a particular file extension to one or more software programs which are supposedly designed to handle the particular file format. For example, clicking on a file ending in .txt will normally result in Notepad being launched. Click a file ending in .vbs in Windows Explorer results in Windows Scripting Host (Wscript.exe) being called, but clicking it in Internet Explorer results in VBScript.dll being called to handle it. By default, Windows has hundreds of file associations. This subtree is used to register and file associations, URI handlers (for example, news://, aim:// in Internet Explorer), and COM file configuration information.

HKCR lists the effective Windows file associations arising from the combination of HKLM\Software\Classes and HKCU\Software\Classes. Starting with Windows 2000, file associations can be viewed or modified in any of the following three registry locations:

  • HKCR

  • HKLM\Software\Classes

  • HKCU\Software\Classes

Although file associations can be modified in any of the three locations, HKCR is only meant to be a registry area showing the effective associations. File associations set at the HKLM\Software\Classes location are, in effect, for all users of the computer unless specifically overridden by HKCU\Software\ Classes. Associations in HKCU\Software\Classes take precedence for the currently logged on user. If a new value is written to HKCR, and it does not exist in HKCU\Software\Classes, it is written to HKLM\Software\Classes and applies to all users on the computer. If the key or value already exists in HKLM\Software\Classes, then the modification is written to HKCU\Software\ Classes and applies only to the local logged on user. This is important point to remember and one occasionally manipulated by malware. Forensic investigators, unaware of the other three file association location interactions might be stymied by malware using the latter two keys instead of HKCR.

Under the registry key HKCR, applications are listed by either their file extension (for example, Vbs), file type name (for example, VBSFile), CLSID (for example, {}), or handling module (for example, Outlook.FileAttach). The HKCR subtree can be broken down into two main sections: upper-level file extensions and lower-level program modules and file associations.

The two different sections allow Windows to bind multiple file extensions into aggregate file types, and to simplify management of these. For example, one might have .bmp, .jpg, .gif, .tif, and so on all pointing to a file type called GraphicFiles, and define actions for these just once, under GraphicFiles. One could then define another file type called AlternateGraphicFiles, and by switching individual file extensions from one to the other, apply different sets of actions without having to destructively set these up for each file extension.

The upper level displays the file extensions that are associated with each registered program. Although most file extensions are three characters long, there are file extensions shorter and longer in length. The upper-level section is mostly a "pointer" to the related lower-level file associations. Together, both levels display a lot of information for each file type. The most important values include:

  • File association

  • File extension

  • Associated program and action

  • CLSID (class identifier)

  • Mime type identifier

  • Default icon

  • File extension display

  • File handling (for example, File Download Confirmation prompt)

At the top of HKCR (using Regedit.exe), you will see *. This subkey tells Windows how to treat all newly registered file types if not instructed by the installing program or user. Directly after the * subkey are hundreds of registered file extensions. Actually, not too much information is stored directly under the file extension subkey, but what is there is valuable and useful. For one, the Default value will list the associated registry key where more of the file association information is stored. For nearly every file association listed at the top of the HKCR key, there is another corresponding lower-level file association subkey holding more confirmation information.

For example, the .Vbs file association has a Default value of VBSFile. VBS-File is a registry key located lower in HKCR and is where the majority of the information regarding the treatment of Visual Basic Script (.Vbs) files is stored. The top file association subkey will also list the CLSID of the associated program in the Persistent Handler value. The CLSID is a unique alphanumeric GUID (Globally Unique Identifier) value given to each program or module. Windows and Internet Explorer often uses the CLSID instead of the file extension to identify a file type handler.

The upper-level subkeys will also reveal MIME Type identifiers. For example, the .Txt file association has the MIME Type identifier listed in the Content Type value with data of text/plain. This means that if a file is downloaded in Internet Explorer (or HTML-enabled e-mail) with a MIME type identifier of text/plain, Windows associates the file with the .Txt file association and the lower level TxtFile subkey (as indicated by the Default value).

Heading down lower into the HKCR subtree will reveal more file association information. For instance, choosing the VBSFile file association (remember the .vbs file association's Default value said VBSFile) displays many key informational fields. First, the Default value right under the VBSFile subkey describes the file type. In this example it is VBScript Script File. Although most administrators are familiar with the most common file extensions and their meanings, there are dozens that are not well known.

If you see URL: < protocol handler> it tells you that the "file extension" is a URL moniker, not a file extension. For example, under the Telnet file association, the Default value has data indicating URL: telenet protocol. This means that if telnet://is typed into Internet Explorer or on the command line it will launch the Telnet program. All the registered URL monikers are a potential attack point because malware can get third-party programs to launch in Internet Explorer. This method has been used in several attacks in the past.

The EditFlags decimal value of 0 (or 0x00000000 in hexadecimal) indicates that a file download confirmation dialog box will be displayed if the file is downloaded by Internet Explorer or other Windows programs and not automatically executed. For potentially dangerous files this is a smart option to enable. If left disabled, a malicious Web site or e-mail could automatically execute malicious code on the user's system without the user ever having a chance to deny the execution.

The DefaultIcon subkey lists the executable the icon graphic is pulled from when an associated file is displayed and the index of the icon inside the file. In the VBSFile example, the icon is pulled from Wscript.exe. Malware has been known to manipulate this value in order to make a potentially harmful file appear harmless (for example, a .exe file associated with the .txt file icon) to trick the end user into executing it without the appropriate cautions.

Some file types point to themselves as the source of the icon, and this is a common point at which malware-type spoofing occurs. When an icon is pulled out of the parent file, the file can display any icon it likes. This is why icons are an unsafe substitute for filename extensions as a determinant of file type, and the risks implied by the file type.

The Shell\Open\Command subkey shows the program the associated file is executed in or with when executed outside of Internet Explorer. In this example, VBSFile is executed with the Wscript.exe program. The Shell\Open2\ Command subkey displays another program, CScript.exe, which can be used to run VBS files at the command prompt. The Shell\Edit\Command subkey displays the program the file is opened in if opened for editing (versus executing). The \Shell\Print\Command subkey tells Windows how to print the file if told to print it (often using Notepad and the /P print command). Other subkeys instructing behavior you might see include New, Printto, and OpenAsReadOnly.

Trojans and worms have manipulated the Shell\Open\Command value so that they were executed along with the normal file handler. For example, many e-mail Trojans have manipulated the .exe file association so that the malware program was executed along with any run .exe executable. They do this by changing the Exefile Default value from its normal setting of “%1” %* to “ malwareprogram.exe %1” %*, where malwareprogram.exe is the malicious program's name. The following file associations are particularly popular with malware programmers using this trick:

  • BAT

  • COM

  • EXE

  • HTA

  • PIF

But any file association is vulnerable. Other Trojans have attacked .chm, .ini, .reg, .scr, and .txt files. The action named as the value of the key called "shell" is the default action that will happen if you double-click (or press Enter on) a file, and will be the action seen in bold if the file is right-clicked to access the context menu. But there are some shell contexts that will use whatever action is called "open" instead, whether this is set as the default action or not. This includes the "legacy" Open With programs list, and use of the Start command.

There are dozens of other possible registry fields related to the registry file associations, but these are the ones most interesting to malware authors and forensic investigators. Messing with file associations in the registry can be difficult and painstaking.

HKey_Current_Users

HKCU lists the current configuration and profile information for the currently logged on user. Virtually any setting that affects the user's desktop experience can be found here, including background graphics, screensaver choices, folders, printer and drive mappings, whether or not the user can see hidden files, and hundreds of other settings. If similar values exist in both HKCU and under HKLM, the data in HKCU takes precedence. The HKCU location is not nearly as popular with malware, but could lead to many of the same exploits accomplished using HKLM.

Spyware uses HKCU more often than any other type of malware. The consequences are that any anti-spyware scanner must be coded to scan multiple user profiles in order to remove all spyware.

HKey_Users

HKU contains all the user profiles on the local computer. When a user logs on for the first time, his or her profile is created using the configuration information stored in the \Users\Default User folder and the HKU\.Default key. Thereafter, when the user logs onto the machine using the same profile, his or her HKU\<profile> information is copied to HKCU for the user's session. The HKU\<profile> is tracked by security principal SID. Any changes made to the user's profile (in HKCU) are saved back to HKU\<profile>. Although malware could take advantage of the profile keys located in HKU, to date they have not messed with it much.

HK_Current Config

HKCC is an alias for HKLM\System\CurrentControlSet\Hardware Profiles\ Current and data it contains can be changed in either location. Windows allows one or more hardware profiles to be created for a computer (choose the System applet under the Control Panel, and then choose User Profiles under Advanced Settings). If desired, varying hardware devices, drivers, and services can be turned on and off per profile. Profiles are most commonly used on laptops, going from docked to undocked states. It has not been frequently manipulated by malware.

The Windows Registry contains thousands of entries. Over the years it has grown in size and complexity and outlived its usefulness. Microsoft plans to replace the Registry with another storage database type in the coming years. However, until the Registry disappears completely, and it could live with us another decade, administrators need to know the most important parts and settings.


Logon Authentication

The process of a user logging on to a computer and accessing local or network resources is made up of many individual components, including an identity, authentication, access control, authorization, and auditing.

Identity

Both computers and users have logon accounts and passwords in Active Directory. Both require unique logon names, and a password (or some other form of unique authentication, such as a smart card or biometric result). The user or computer account name must be unique in the namespace (i.e. Security Account Manager or Active Directory database) it is attempting to authenticate and log on to successfully. In computer security circles, the unique logon account is called an identity.

Note

In Vista, security principals can authenticate themselves with a wide range of authentication methods, including passwords, smart cards, and biometric identification devices. In this chapter, whenever the word "password" is used, it should be understood to stand for any sort of valid supplied authentication credential. The word "password" is being used to make the overall concepts easier to understand.

To be completely accurate, two security principals can share the same logon or display name, but the entire name path (called absolute path) in the authentication database or directory service must be unique. Hence, there can be two rgrimes in Active Directory, but only one rgrimes in a particular organizational unit location. The following examples would be valid in the same authentication database:

     \Washington\Users\rgrimes and \Virginia\Users\rgrimes

A single user, or for that matter any Windows object, can appear only once in a directory structure. The same rgrimes cannot appear in the two places at once. If there are two rgrimes accounts in the same directory service, they are not the same object.

Authentication

When the user or computer supplies the correct password, the security principal is considered authenticated. If using the Kerberos authentication protocol (covered shortly), the authenticated user or computer should not need to supply its password again, if it keeps the same token for the next 10 hours to participating domain resources. And even after 10 hours, the computer will usually authenticate the user automatically using the credential supplied during the original logon.

Computer Accounts

After a computer boots up and loads Windows, it logs on to Active Directory with a logon name and password. The computer's account name is its host-name (for example, LabPC1) followed by a $ (for example, LABPC1$). The computer account is created when the computer is first joined to the domain.

Note

Standalone computers do not have computer accounts or authenticate to a domain.

At the time the computer account is created, Windows also assigns the computer a random password. The password is complex and long, and automatically changed every 30 days by default. The maximum password age can be changed using a registry edit, group policy, or local computer policy. In group policy, the maximum machine account password age can be changed at the following location:

     \Computer Configuration\Windows Settings\Security Settings\Local Policies\
     Security Options\Domain member: Maximum machine account age.

There should hardly ever be a reason to change the maximum password age, however. The password is so long that it should never be crackable within any of our lifetimes, and if it is compromised in clear text, the attacker has penetrated so far that changing the password is meaningless.

After the computer has successfully logged on, its password is used by a cryptographic function to establish a secure and authenticated communication channel (using RPC and SMB) between the computer and the domain controller. The computer's password is also used to establish IPsec authentication, to store other machine-specific cryptographic secrets, and for many other Windows processes requiring end-point security.

Password Storage

When a user enters their password for the first time, it is converted by a cryptographic hash algorithm to its representative obfuscated form and stored in the authentication database (SAM or Active Directory) in its hashed form. This is to complicate the job of password crackers gaining unauthorized access to the authentication database. Because the password is not stored in its plain-text form, a hacker obtaining a password hash must convert it from the hashed form to the original plain-text form. Sometimes this is a trivial process. Other times it is impossible. The longer and more complex the password is the more difficult the conversion process.

Windows has two password hash forms:

  • LAN Manager (LM)

  • NT

The LM password hash, developed in the early 1980s, isn't a strong cryptographic hash, and is trivial to convert to the original, plaintext form. The NT hash is a strong hash, and if the password is sufficiently long and/or complex, it is very difficult to convert. Prior to Vista, Windows stored all passwords in both hash forms, unless the password was greater than 14 characters long or if it contained unsupported characters (for example, extended ASCII). If crackers gained access to the password authentication database, they would dump the LM hashes, ignore the NT hashes, and quickly break them all.

Note

A good cryptographic hash has three properties:

  • Every identical input creates the same identical output every time.

  • Different inputs create different outputs.

  • If an attacker obtains the hash output, they cannot easily find the corresponding original plaintext input.

Starting with Windows Vista, Microsoft stores passwords in their NT password hash form only. This one change will significantly decrease the risk of password cracking from a compromised authentication database or from onthe-wire sniffing.

Authentication Protocols

Windows 2000 and later support four different authentication protocols:

  • LAN Manager

  • NTLM (version 1)

  • NTLM (version 2)

  • Kerberos

Note

Actually, there are two other authentication protocol versions, LAN Manager version 2, plus an unnamed, modified version of NTLM, but we will not be discussing them separately.

An authentication protocol is used to communicate the user's inputted password between the client and the authentication database service during a logon event. Plain-text passwords should never be sent across the network, although they often are depending on the protocol, program, or application being used. A hacker could sniff the network and pull out the plain-text password. Even password hashes should not be sent across the network. A network sniffing attacker could grab the password hash and begin cracking it, or worse, use it to authenticate directly to the network service without cracking. This is possible because of how challenge-response protocols work. For more information on this topic see Chapter 11 of Protect Your Windows Network: From Perimeter to Data by Jesper M. Johansson and Steve Riley.

Instead, Windows uses a challenge-response authentication protocol to communicate possession of the password between the client and the server. In all four authentication protocols, the client requests to log on to the authentication database service. The client sends its logon name along with the host, workgroup, or domain requested, and other identifying or requested information. The authentication database service creates a random challenge value in the form of hexadecimal characters. The client receives the challenge characters and, using the hashed form of the inputted password mathematically manipulates the challenge using the chosen authentication protocol mathematical algorithm, to create the response.

The response is sent to the server. The server performs the same calculations on the challenge that it sent using the hashed form of the user's stored password, and if the server's calculations agree with the sent response, the user is considered successfully authenticated (because only a client with the correct password could have the correct password hash and could have correctly calculated the expected response).

This allows the client's inputted password to be communicated to the authentication database server without ever sending the password or the password hash across the network. Can the password hash still be recovered if the network is sniffed? Sure. If the attacker sniffs both the challenge and the response, the authentication protocol algorithm calculations are well documented and the password hash can be re-constructed from the captured challenge-response data. Still, it complicates network password sniffing, and if the password hash is NT (versus LM) and the password isn't simple, it doesn't' matter anyway because the password hash will be non-trivial to convert.

As stated previously, Windows 2000 and later support all four authentication protocols. Windows NT and Windows 9x computers, fully patched, support three authentication protocols excepting Kerberos. Kerberos and NTLMv2 authentication protocols are considered strong, while LM and NTLMv1 are considered weak and crackable.

By default, Windows 2000 and later domain computers will use Kerberos authentication to connect Windows 2000 and later domain resources. Otherwise (for example, local logons, legacy domains, and so on), they will send responses with both LM and NTLM. Windows Server 2003 will send only NTLM, and starting with Windows Vista, only the NTLMv2 protocol is sent for non-domain authentication. All Windows NT-based operating systems since Windows 2000 with the Security Rollup Pack 1 will accept all four (six if you count the other two undocumented) authentication protocols inbound by default. Preventing the older, insecure, protocols from being sent, as is done by default in Windows Vista prevents many password sniffing attacks and further strengthens Windows.

SAM Versus Active Directory

It's important that a Windows security administrator know where Windows logon passwords are stored. Security principal account names, their password hashes, and other related information can be stored in the local Security Accounts Manager (SAM) database or in the Active Directory database (Ntds.dit) on domain controllers. Every NT and later computer has a SAM database for local accounts. SAM databases are even used for domain authentication in NT 4.0 domains. However, only Windows 2000 and later domain controllers have Active Directory databases for domain accounts and passwords (among other things).

And on Windows 2000 and later domain controllers, the local SAM contains only two accounts: a disabled Guest account and the local Administrator account (also known as the Directory Services Restore mode Administrator). The local Administrator account can only be used only when the domain controller is rebooted in Safe mode, Directory Services Restore mode, or in the Recovery Console.

Why is this important? Because many password cracking tools crack only SAM databases and not Active Directory databases. There are about two dozen different, popular, Windows password cracking tools, with names like Pwdump, Lophtcrack, SAMJuicer, and so one. Most of these can only extract password hashes from SAM authentication databases-and most of those do not work against Windows Vista.

Note

Chapter 4 of the ebook Keeping Your Business Safe From Attack: Passwords and Permissions by Roger Grimes (http://www.windowsitpro.com/ebooks/?fuseaction=ebook&ebid=&code=) covers many password cracking tools and methodologies. Downloading the ebook requires Web site registration.

Cache Credentials

When a user successfully logs on to a domain from a local member computer, the user's logon credentials are stored and cached on the local computer. By default, Windows will locally cache the last ten user credentials that logged to a domain from a given computer, although that value can be modified to be anything between 0 (no cached credentials) and 50.

If the computer is unable to connect to a valid domain controller during a future logon attempt (for example, roaming laptop), Windows will use the cached domain credentials from a previous successful logon instead. This allows users to have the same user profile and desktop settings as they get when they successfully authenticate to a domain controller. Without this feature (and it can be disabled), a laptop user who disconnected from their domain would have to log on with a second local logon account name, and would receive a different user profile. Keeping both the domain and local user profile would be problematic for most users.

By default users using a cached credential will not be notified that the domain authentication event was unsuccessful. Instead, they will be allowed to logon like they normally do, except that it takes a little longer and they will notice that network resources are not available.

Note

There is a common misunderstanding that Windows will only allow a single user to log on ten times if their domain controller cannot be contacted. In reality, the logic is that the cached credential feature will let the last ten different users that logged onto the domain previously from the same computer to log on an unlimited number of times.

Windows stores a hash of the cached logon password as an encrypted MD4 hash that has been salted (i.e. a value is added to the secret before salting to make cracking more difficult) with the user's name and computed twice. Prior to Windows Vista, if a malicious attacker had local Administrator access and the appropriate hacker tool (for example, Cachedump.exe or Cain & Able) they could retrieve the stored cached password hash and attempt to convert it to the plain-text original. Windows Vista has invalidated both attack tools and further strengthened the storage of the cached password hash by encapsulating the salted MD4 hash using the PKCS#5 encryption key derivation function. This makes it effectively impossible to crack should an attacker manage to capture the cached credentials. Security administrators wishing to force a valid domain logon every time should disable cached logons, but should realize that they will need to use local accounts if the domain cannot be contacted-for example, if there is a network card failure that needs troubleshooting.


Access Control

Once the user (or computer) is successfully authenticated, an access token is created containing the user's security identifier (or SID), the groups they belong to, and the privileges they possess, among other security related items. You can see a particular listing of your access token by typing Whoami /all at a command prompt (see Figure 3-23).

Image from book
Figure 3-23: Partial access token listing using Whoami /all

When the user attempts to access a Windows resource or object, their effective access is determined by the common points between the values and memberships in their access token and the resource's access control permissions (more on this in Chapter 5).

Share Versus NTFS Permissions

Windows file sharing has two types of permissions: Share and NTFS. If the user is connecting to a remote computer over an SMB share, Share permissions apply in addition to file system permissions, and the user must have the requisite access in both places for the access to succeed. Actually, Share permissions apply even if accessing the local computer using a SMB share (although that would be strange and unnecessary). Share permissions can be set on folders and printers (but cannot be set at the file level), and are available on both FAT and NTFS partitions.

NTFS permissions apply to every object on an NTFS partition (file, folder, printer, registry key, and so on), and apply whether the user is accessing a local or remote resource. NTFS permissions even apply to objects accessed using other methods besides SMB. For example, files and objects accessed through IIS are protected with NTFS permissions if stored on an NTFS-formatted partition. The remote user, accessing IIS using the WWW service or using FTP, is bound to the NTFS permissions set by the web administrator. In contrast, Share permissions do not apply on files accessed outside of SMB shares.

Impersonation Versus Delegation

Any time a user accesses an object that is protected by Windows security, it must do so through a Windows process, whether that is an application or a service. For instance, the user never directly accesses a file. File access is always through a program, such as Windows Explorer, Microsoft Office, or some other application or service-even the Command Prompt is an application. The process accessing the object on the user's behalf often acts as the user, and we say that its primary token is the same as that of the user.

Other programs-some servers, for instance-will receive credentials from the user, in the form of a password or an SSL certificate exchange, and use these credentials to impersonate the user. An impersonation token is different from a primary token and is not able to be used to create a new process as the impersonated user.

Since impersonation requires that the user present credentials to the process, which is generally a remote process, it is under the user's control as to which processes are trusted to impersonate that user.

Delegation, by comparison, is a method by which a process can claim to be a user without presenting any identifying credentials and without being initiated by the user. Delegation is often used by web servers in situations where the user can be recognized to the web server's satisfaction without providing entire Windows logon credentials.

Delegation is controlled by marking a system as Trusted for Delegation and should be carefully limited to servers that you trust to identify users and act on their behalf-a server trusted for delegation could claim to be a Domain Administrator, for instance.

There are some actions that positively require the use of a password-decrypting files protected by EFS, for instance, is governed by a private key that is encrypted using a key derived from the user's own password. If you do not know the user's password, you cannot use the user's private keys, and you cannot decrypt files on behalf of the user. (You are able to give the raw, encrypted bytes to the user's process, for that process to decrypt with the user's key-that may look as if the server is decrypting the EFS file without access, but the decryption is really done locally.)

Integrity Controls

As previously discussed in Chapter 1, Vista introduces the concept of mandatory integrity controls to Windows. Every user account, file, object, application, and process in Windows has an integrity level. Integrity levels are:

  • Low

  • Medium

  • High

  • System

Most users and objects have a Medium integrity level. Even members of the Administrators group, who are not the true Administrator, only have Medium integrity when not elevated. The real Administrator has High integrity. Most Windows services and kernel mode programs run with System integrity. Internet Explorer in Protected mode runs with Low integrity. Any object without an integrity level is automatically treated as having Medium integrity.

Actually, there are at least two other integrity levels used by Vista, but rarely seen: Anonymous and Protected Process. The Anonymous integrity is assigned to anonymous null session connections. This makes unauthenticated connections less of a threat than they were in previous Windows versions. Protected Process integrity is used by the system for integrity needs beyond System.

Child processes or objects created by a parent process or object normally gets assigned the same integrity process of the parent. User or objects of lower integrity cannot write to objects of higher integrity, no matter what their NTFS or Share permissions are. Users or objects can write to objects or processes of the same or lower integrity, if their assigned NTFS permissions also allow it.

Integrity levels can be viewed by using the new Icacls.exe command-line program. Initially, Microsoft wants integrity levels to be used to prevent unauthorized writes, but mandatory integrity controls can also be used to prevent Reads and Executions programmatically.

The net result of integrity controls is that users, even Administrators, will have a harder time modifying system files and processes. Programs and malware arriving via Internet Explorer running in Protected mode (i.e. Low integrity) will have an even harder time manipulating everything else in Windows (not marked with Low integrity). This should reduce the number of malware programs that silently modify and infect Windows through Internet Explorer. Integrity controls are yet another defense-in-depth control that Microsoft has added to Windows.

Items of lower integrity cannot modify items of higher integrity, regardless of the Share or NTFS permissions.


Summary

We hope you have learned a few things about Microsoft Windows that you did not know before. All of the concepts covered in this chapter are important to understanding and setting security in Windows Vista. Chapter 4 covers Vista's most important security improvement, User Account Control.


Part II: Host-Based Security

Chapter List

Chapter 4: User Account Control
Chapter 5: Managing Access Control
Chapter 6: Application Security
Chapter 7: Vista Client Protection


Chapter 4: User Account Control

User Account Control (UAC) is probably one of the most visible, and most talked about, security features in Windows Vista. Whenever you attempt to take an action that only administrators can perform you get a dialog box asking whether you really want to do this, as shown in Figure 4-1.

Image from book
Figure 4-1: UAC approval dialog box for administrator in admin-approval mode

Despite the visibility of, and all the opinions about, UAC, we do not believe that most of the discussion is carried out in light of what UAC really is. In fact, there seems to be some real confusion out there. It is very clear that many pundits have not bothered to fully understand UAC, what it is, and how it works. They write blog posts, newsgroup postings, and articles with titles like "Vista's most annoying feature" and they pontificate on how many people will turn it off, and why it is so annoying in the first place.

Unfortunately, much of the advice to turn off UAC is based on an initial experience. You should expect that, while you are configuring your computer, you will have a very different administrative experience than you will have once the computer is in a steady state. The first few weeks will be quite different from the following few weeks.

Introduction

UAC is Microsoft's long-awaited solution to the problem that 90+ percent of end users on the Windows platform run with administrative privileges. That means that malware that attacks the users themselves, or the applications they run, will have the run of the computer on 90 + percent of the systems they see. On Windows XP, you can run as a regular user, but for many of us, it is plain painful. For instance, if you travel across multiple time zones you find that as a regular user it is unable to modify the time zone.

UAC is actually a collection of technologies that Microsoft developed to achieve several different goals. In this chapter we introduce you to UAC. We tell you what it is, and why it is implemented the way it is. We attempt to answer some common questions about it, and finally, we give you our recommendation for how to manage it. We should be honest up front: We do not hate it, and both of us believe it is an important security feature. We both leave it on for ourselves and our users. We do not have any illusions, however, that it is a panacea. Between the two of us, we have run our computers with it turned on for over a year and a half, through various betas. While this may not seem like a great deal of time, it has given us a fair amount of experience with it. Given how controversial it is, we try to be as objective as we can, presenting you with the facts so that you can make your own decisions about how to manage UAC.

Before we jump into our discussion, here are a few facts about UAC:

  • While sometimes it's frustrating, it is not deliberately designed to be the most annoying feature in the history of Windows.

  • It will not stop really good attackers, or those that have the help of really good attackers. UAC is designed to set us on a path where users do not need to expose their system to potentially malicious code as often as they do today. That does not mean that successful privilege elevation attacks will not occur. If the bad guys can't think of any other way to defeat UAC, they will almost certainly resort to asking the user to do it for them. Given the choice of dancing pigs and security, we know from experience that the dancing pigs will win every time. UAC does not provide foolproof security. In fact, it makes the good old local privilege elevation attack interesting again. These attacks have largely been discounted because, on Windows, nearly everyone was an admin anyway so elevating to some other admin was quite pointless. That being said, UAC definitely changes the nature of such attacks, and to that end, changes the rules of the game to ones similar to what we have had on Unix for 20+ years.

  • It will not stop bad guys from stealing your personal data. A user's personal data is accessible to that user, regardless of that user's privilege. As such, an application, including malicious ones, can access it. UAC does not, and cannot, change that. It does not remove the need to be vigilant, distrustful, and paranoid-attributes that we should all instill in our end users.


Basics

UAC is part of a long-term strategy to change the way application developers write code and the way we as end users use the software they write. The idea is to reduce the inherent exposure in having the majority of Windows users running as an administrator all of the time. Unix has long had a toolset and basic architecture designed around the idea of least-privilege. Windows has an architecture that supports using the least possible privilege to perform the task at hand, but that is unfortunately not how the system has been used. First, there is a huge legacy of applications that were written under the Windows 3. x and 9 x model that everyone was an administrator. To use those applications, virtually all developers ran as administrators, and consequently, the code they wrote was never designed to run with least privilege. Microsoft's own developers did this too, which meant that very little of the operating system or other applications were really designed to take advantage of the least privilege model.

By the time Microsoft started actually thinking seriously about helping end users run as non-administrators, it became very obvious, very quickly, that their ability to do so was virtually non-existent for the vast majority. The "Run As …" command was introduced in Windows 2000 to allow a user to elevate a task without having to log off and back on again. However, it was so inadequate to the task that it went almost entirely unused, save for a few brave and honorable people who wrote scripts to make it more usable. To fix this problem required a fundamental architecture change. UAC is where this architecture change was first delivered. In a way, it is version 1 of Microsoft's effort to enable people to run with least privilege. One of its primary goals is to mitigate poorly written applications so that more people can run as standard users, thereby forcing ISVs to write more applications that run as standard user. If people turn off UAC, this goal will never be met.

In order to enable UAC a number of fundamental structures in the OS needed modification. We will begin our exploration of UAC with those structures.

Security Identifiers

Most people that use a Windows NT-based operating system (OS), including Windows 2000, Windows XP, Windows Server 2003, and Windows Vista, are aware that users are associated with user names in the operating system. Under the hood, however, the user name is not the actual item identifying a user. Under the hood the operating system uses a Security Identifier (SID). A SID is a globally unique numeric value that identifies a user, a subject in computer security parlance, in the system. Subjects include not just users but also groups, computers, domains, and, in Windows Vista, even some processes. The SID is composed of an authority that issues the SID, a set of one or more sub-authorities, and finally, a relative identifier. In text form, a SID may look as follows:

     S-1-5-21-57989841-1336601894-682003330-500

Everything in this SID up to the last part (–500) is the SID for the computer or the domain itself. The last part makes this a SID of a user. Analyzing the pieces separately, we start with S, which stands for SID. 1 is the revision level, or version number of the SID format.

5 is the identifier authority that issued the SID. 5 is the numeric representation of SECURITY_NT_AUTHORITY, or the Windows NT operating system (remember that Windows Vista is just the trade-name for the latest in a line of Windows NT-based operating systems, which explains why it is Windows version 6.0.6000 internally).

21 is the first sub-authority, which stands for SECURITY_NT_NON_ UNIQUE, and means that this SID may not be universally unique. There may be other computers out there that have exactly the same SID as this one.

The next three blocks are sub-authorities that identify the computer. You may see varying numbers of these sub-authorities, particularly on SIDs issued from domains.

Finally, we have the Relative Identifier (RID). A RID of 500 always identifies the BUILTIN\Administrator account, which exists on all Windows computers. A RID of 501 indicates the built-in guest account. The actual RIDs for users you create typically start at 1000 or 1100, depending on the exact operating system you are using. RIDs are incremented each time you add a user. Even if a user is deleted the RID is never reused on the same system. This is why you get the warning that each user is identified with a unique identifier when you try to delete a user account. Creating a new user with the same name as a deleted one still makes it a different user as far as the operating system is concerned because it has a different SID.

SIDs are used in many situations beyond those that are within the scope of this book. There are entire books that address the topic. See the references in Appendix B for further useful sources of information.

Security Token

When a subject logs on the OS constructs a security token, sometimes called an access token, for the subject. The token contains essential information about the subject. In addition to the subject's own SID the token also contains all the SIDs of all the groups the subject is a member of, along with a list of all the privileges and rights the subject has been granted. In Windows Vista, you can view the complete contents of your token with the whoami command.

Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.
C:\Users\Jesper>whoami /fo list /all
USER INFORMATION
----------------
User Name: jj-vistartmtst\jesper
SID:       S-1-5-21-604828993-3653798594-2491376708-1000

GROUP INFORMATION
-----------------
Group Name: Everyone
Type:       Well-known group
SID:        S-1-1-0
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: BUILTIN\Administrators
Type:       Alias
SID:         S-1-5-32-544
Attributes: Group used for deny only
Group Name: BUILTIN\Users
Type:       Alias
SID:         S-1-5-32-545

Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: NT AUTHORITY\INTERACTIVE
Type:        Well-known group
SID:         S-1-5-4
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: NT AUTHORITY\Authenticated Users
Type:        Well-known group
SID:         S-1-5-11
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: NT AUTHORITY\This Organization
Type:        Well-known group
SID:         S-1-5-15
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: LOCAL
Type:        Well-known group
SID:         S-1-2-0
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: NT AUTHORITY\NTLM Authentication
Type:        Well-known group
SID:         S-1-5-64-10
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: Mandatory Label\Medium Mandatory Level
Type:        Unknown SID type
SID:         S-1-16-8192
Attributes: Mandatory group, Enabled by default, Enabled group

PRIVILEGES INFORMATION
----------------------
Privilege Name: SeShutdownPrivilege
Description:    Shut down the system
State:           Disabled
Privilege Name: SeChangeNotifyPrivilege
Description:    Bypass traverse checking
State:           Enabled
Privilege Name: SeUndockPrivilege
Description:    Remove computer from docking station
State:           Disabled
Privilege Name: SeIncreaseWorkingSetPrivilege
Description:    Increase a process working set
State:           Disabled

Privilege Name: SeTimeZonePrivilege
Description:    Change the time zone
State:          Disabled

Every process that runs on the user's behalf gets a copy of the token. This process token, as it is referred to when it is attached to a process, contains much of the same information as the security token. It will also have additional information related to how it may be used, and whether it has some things removed. A process the user runs directly receives a primary token. By contrast, a process run on the user's behalf by something else, such as when a computer is performing some task on behalf of a remote user, gets an impersonation token. An impersonation token is essentially used by a process to "spoof" the subject. See the sidebar "Impersonation versus Delegation" for more information on impersonation.

Image from book
IMPERSONATION VERSUS DELEGATION

The difference between impersonation and delegation is not well understood in many circles. Impersonation, as we mentioned, allows a process to act on behalf of a user to access resources local to the remote system on that user's behalf. Normally the user is a client of the process, and the process provides some service on behalf of the user. For example, when a user accesses a shared resource on a server, the server service on that server can request an impersonation token for the user. The server service can then launch a separate thread using that impersonation token and attempt to access the requested resource. The access check against the resource (see Chapter 5 for more details on access checks) will take place against the impersonation token of the client, not against the process token of the server service. This allows for very simple and efficient access control.

Impersonation tokens are restricted such that they are valid only on the system they were issued on. This helps contain attacks. To see how, assume a malicious user replaces the server service with a fake service and then entices a user to connect to it. The fake server service now receives an impersonation token for the user, but it can only be used to access local resources on the system the attacker already controls. In other words, it gives the attacker no extra access beyond what he had before.

In order to allow processes to request access to network resources on behalf of users delegation is used. Delegation is the impersonation of clients over the network. If a server is trusted for delegation it can create tokens which can be used in network requests to access remote resources. This makes delegation a very sensitive operation and trusting something for delegation essentially means making it as sensitive and powerful as any domain controller. A subject that is trusted for unconstrained delegation can perform any task in the domain on behalf of any user in the domain. In Windows Server 2003 constrained delegation, which restricts the actions the trusted subject can take, was introduced specifically to allow more control over this sensitive area. To learn more about impersonation and delegation, refer to the Windows Software Development Kit.

Image from book


The Case for Least Privilege

Several years ago, when Microsoft launched its "Protect Your PC" marketing campaign, it promulgated three requirements as paramount to security:

  • Fully patched system

  • Firewall installed and running

  • Up-to-date antivirus

There were a few rebels, including the two authors, who claimed that not only was one item missing, it was more important than at least one of the three on that list: not running as an administrator. The reason why Microsoft left that particular one out though was very clear: you can't have more than three top-three most important security features. And, Windows XP, which was the current client operating system at the time, did virtually nothing to help people run as a non-admin. The reason for this was really easy: the number of software developers, both at Microsoft and outside, that ran as non-admins was, well, if not zero, so certainly in the single-digits. The number of software developers outside Microsoft that ran as non-admins was lower still. The number of program managers at Microsoft that ran as non-admins was around two. In fact, and perhaps even more appalling, the number of marketing folks involved in the Protect Your PC campaign that ran their day-to-day workstation as nonadmins was also hovering around zero!

The fact was that almost nobody that had responsibility for the OS, or any app running on it, ran as a non-admin! The result was very predictable: it was virtually impossible for end users to run as a non-admin unless they were either quite savvy, or had a significant support structure to do the things they couldn't do. To make things even worse, the public did not demand applications that ran with least privilege on a broad scale. We all kept buying applications that would only run if we were admins. This did not give Microsoft or Independent Software Vendors (ISV) much of an economic incentive to develop better applications.

There were some lone voices in the wild. Our good friend Aaron Margosis was pontificating on his blog (http://www.blogs.msdn.com/aaron_margosis/default.aspx) about how to run as a non-admin. So was Michael Howard (http://www.blogs.msdn.com/michael_howard/). A few brave souls, Keith Brown (http://www.pluralsite.com/wiki/default.aspx/Keith/HallOfShame.html) and Susan Bradley (http://www.threatcode.com/), started trying to shame developers into fixing their products by listing software that does not work properly as a non-admin.

So, what's the fuss about? Why is least privilege such a big deal? Well, simply put, because of the power that admins wield.


Admins Are Omnipotent

Admins are omnipotent-all the time. Even when you only log on to read e-mail. Or surf the Web. Or download files from your favorite file sharing service. Or write a letter to your congressman. Or accidentally click on an attachment that you shouldn't. Or when your kid chats with friends online.

Those tasks, when taken by a user that is an administrator, have complete and unfettered access to the computer. Any one of those tasks, or any task that manages to subvert one of them, can do absolutely anything on the computer: steal all your personal information and send it to a criminal syndicate in a country you've never heard of, install new rootkits when you stick a music CD into your comptuer, upgrade existing rootkits when you log on, use your computer to attack the Federal Reserve Bank of San Francisco, install adware, spyware, botware, malware, and trojans. All of it. All while you, or your kids, or your aging parents, or your dog, are surfing the Web for information on, say, scuba diving in Sharm El Sheikh (http://www.sharmguide.com/). Two years ago, Intel CEO Paul Ottellini revealed that he spends an hour a week removing spyware from his daughter's computer. Notwithstanding the obvious questions of what Web sites this computer goes to, you cannot help but wonder how many hours he would spend if she were not browsing the Web with admin privileges. As it were, each accidental click does not have to result in spyware being installed, if you do not browse the Web as an admin. Sadly, doing so was not exactly easy.

The point we are trying to get across, not particularly succinctly, is that the vast majority of things you do when you run your computer on a day-to-day basis are not inherently administrative tasks. Yet, too many of them require administrative privileges. Therefore, because it is too painful to figure out how to make what we need to do work without being admins, we make everyone an admin. This is what enables so many attacks against users to be so successful.

UAC was designed as a first step toward rectifying this situation. The primary goals of UAC, included making many more people able to run as nonadmins most of the time.


User Account Control Is More Than You Think

UAC is designed to meet a number of goals:

  • Increase the number of end users that can run as a non-administrator the majority of the time.

  • Decrease the number of scenarios that require elevation to an administrative account.

  • Make elevation considerably easier-automatic if possible-than the current kluges using runas.exe or just logging out from one account and in with another to bridge the gap until ISVs fix their applications.

  • Provide some protection of applications running as an administrator from those that are not.

  • Enable certain exposed applications to run with even fewer privileges whenever possible.

Only one of those goals deals with the actual elevation task. Yet, the elevation, when an application asks for additional privileges, is what people complain about. The first, overarching, goal has nothing to do with elevation. It is only to enable more people to run as non-admins more of the time.

The next two goals are designed to make the user experience of running as a non-admin as palatable as possible. Finally, we have two goals that are designed to protect applications that are particularly exposed.

What is important about these goals is that only two of them are related to the feature that is popularly seen as "UAC." Goal number 3 is about making elevation easier than what it was in Windows XP, and goal number 4 is about protecting applications that are running elevated. The remaining goals have to do with something that is essentially non-technical, or with a technology most people never notice. Each of them required changes to the operating system, however.

In the remainder of this section we will investigate the changes that were made to the OS to meet each of these goals. Some changes contribute to several of the goals, and some contribute to only one or a few.

Elevation

Core to UAC is the ability to easily elevate to a full administrator. By default, even members of the administrators group are not running with a full administrative token. This means that some tasks that would have been possible under Windows XP do not work under Windows Vista the same way. Consider, for instance, Figure 4-2.

Image from book
Figure 4-2: Modifying or deleting files in %ProgramFiles% and %windir% does not work even as an administrator.

Even when a user is logged on as a member of the Administrators group they are by default placed in what is called admin approval mode. The user's security token, by default, has the Administrators SID marked as Deny, as shown in Figure 4-3. This means that it is used only to deny access, never to allow it.

Image from book
Figure 4-3: Administrators, by default, have a token that marks the Administrators SID for Deny.

A security token with the Administrators SID set to Deny is called a "filtered token." A user with such a token cannot do anything more on the system than a regular user. Note also that the privileges shown in Figure 4-3 contain only a set of relatively benign privileges associated with a regular user.

If a user needs to perform an administrative task, the user needs to elevate. The elevation can be initiated by the program that is being executed, in several ways that we shall see later. It can also be initiated by the user, by right-clicking the program and selecting "Run as administrator," as shown in Figure 4-4.

Image from book
Figure 4-4: A user can initiate elevation of a task by right-clicking the program and selecting "Run as administrator."

Initiating elevation of a task causes the OS to switch the user into what is known as the "secure desktop." In Chapter 6, we cover desktops in detail. For now, it is sufficient to know that all user applications run within a structure known as the "desktop." Each user has a separate desktop, and the OS has one that it uses for security sensitive tasks-the secure desktop. The secure desktop is used to host security sensitive functions, such as the logon dialog boxes, and UAC elevation prompts. The secure desktop cannot be programmatically driven by ordinary applications. This means that while applications that run on a user's desktop can interact with user interface components of other applications on the same desktop, they cannot do the same with user interfaces shown on the secure desktop. For this reason, Windows Vista, by default, puts the elevation prompt on the secure desktop, as shown in Figure 4-5.

Image from book
Figure 4-5: Elevation prompts are shown on the secure desktop by default.

Knowledge of the secure desktop allows you to answer the very common question of why the screen goes dark. You are actually not looking at your screen at all. The OS takes a screenshot of your screen, switches to the secure desktop, puts a grey mask over the screenshot, and shows that as the background of the secure desktop. This explains why a moving user interface component appears to be frozen when the UAC elevation prompt is up.

You can disable the switch to the secure desktop using Group Policy. The setting is under Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/User Account Control: Switch to the secure desktop when prompting for elevation. This is actually necessary if you need to use Vista's speech recognition feature to control user interface elements. However, for most users, it is highly recommended that you leave the defaults in place.

A very common complaint of Windows Vista is that the switch slows down the computer. In our testing, (using a virtual machine running in Virtual PC 2007 on a relatively moderate laptop, as shown in Figure 4-5) the switch takes less than half a second. On reasonable hardware, it should be virtually instantaneous. If you find that it takes a noticeable amount of time, you most likely have a video driver issue. Check with your computer Original Equipment Manufacturer (OEM) or the manufacturer of your video card to see if there is an updated driver available.

Once the process is elevated it has a full administrative token, as shown in Figure 4-6, which is a screenshot of Microsoft's Process Explorer, showing the token for an elevated command prompt process.

Image from book
Figure 4-6: An elevated process has a full administrative token.

The prompts shown in Figures 4-1 and 4-5 are both for built-in components that are signed by Microsoft. Signed, non-Microsoft binaries have a prompt that looks almost identical, but the field underneath the "Windows needs your permission to continue" prompt is grayer. This extremely slight color difference is meant to alert users that the prompt is not as highly trusted.

Far easier than telling Microsoft v. non-Microsoft signed binaries apart is telling that a binary is not signed at all. The elevation dialog box for an unsigned binary is shown in Figure 4-7.

Image from book
Figure 4-7: An unsigned binary has a different elevation dialog box.

When attempting to elevate an un-signed binary the elevation dialog box has a yellow bar at the top and the text is different. The dialog box also looks different, as shown in Figure 4-7.

By the way, Iexplore.exe is Internet Explorer, and no, it is not actually unsigned. It shows up this way on purpose to warn people not to elevate Internet Explorer, according to Microsoft.

The theme of the UAC dialog boxes is used throughout the operating system. A very similar dialog box is used when installing unsigned drivers. This dialog box, shown in Figure 4-8, has a red bar, and presents similar information to the UAC dialog boxes.

Image from book
Figure 4-8: Unsigned driver installation dialog box

The elevation dialog boxes are also used in Internet Explorer (IE) when it attempts to install an ActiveX control. IE will first prompt that the site is attempting to install the control using the familiar information bar that was introduced in Windows XP Service Pack 2, shown in Figure 4-9.

Image from book
Figure 4-9: IE will prompt for installation of ActiveX controls.

The gold bar in Figure 4-9 is shown only if the user is an administrator in admin-approval mode. If the user is a standard user, or if the admin chooses to install the control, we proceed directly to a UAC prompt. This prompt is, unfortunately, the least informative prompt in all of UAC, possibly all of Windows. It is shown in Figure 4-10.

Image from book
Figure 4-10: The IE ActiveX Control installation prompt is not particularly useful.

Exactly how you are supposed to make any intelligent decisions based on this prompt is quite unclear and it is even more unclear if it pops up from a Web site that is less obvious than the one in Figure 4-10. Information about what exactly the system is trying to install is, for all practical purposes, lacking. Instead, the system shows a Globally Unique Identifier (GUID). To make any sense of this you would have to write it down, and then search the Internet for any information on it. However, just as in the case shown in Figure 4-10, you would find no information in most cases. The user is, in other words, left entirely on his or her own trying to decide whether to accept this object. If he does, he will get to see the naked dancing pigs, so it is unlikely that security will stand a chance.

To be completely fair here, however, we should point out that if you hit Continue in the dialog box shown in Figure 4-10, you get another dialog box that asks again if you want to install this control. That dialog box is from Internet Explorer, and it does show the name of the control.

Non-Admin Elevation

All the dialog boxes for elevation shown so far are those that appear to a filtered admin, a member of the administrators group when UAC is enabled. As mentioned earlier, this mode of operation is called admin approval mode. Running day-to-day in admin-approval mode is definitely a security improvement versus the way we ran in Windows XP: admin always mode. However, when elevating an application in admin-approval mode, the application receives the exact same user environment as the applications running with a filtered token. Theoretically, exploits can be crafted that poisons a filtered admin environment such that when the user elevates, the exploit also gets elevated. We are not aware of any such exploits as of this writing. Nevertheless, it is very likely that some will surface eventually. Only by running as a standard user can you combat those exploits. Users are not made standard users by default because too many applications currently require elevation, and it is felt that giving users two accounts-one standard user, one admin-is too cumbersome.

When running as a standard user the process token looks almost identical to the filtered admin's token, with the exception that the standard user does not have the Administrator's SID in the token at all. Applications are elevated with exactly the same process as before, but the prompt now prompts for credentials instead, as shown in Figure 4-11.

Image from book
Figure 4-11: The elevation prompt when running as a standard user

The elevation prompt is still on the secure desktop and so is protected against sniffing attacks. Contrary to runas.exe under Windows XP, elevation also works against an administrator account that does not have a password, although the prompt still will show a password field. The prompt also shows all the administrators on the computer. It even starts scrolling if there are more than five. Unfortunately, there is no way to turn this off and to require that the user know a valid administrative account name.

A process that is elevated by a standard user still runs within the user's desktop, and is a child process of Windows Explorer, as shown by the tree view in Process Explorer in Figure 4-12. Note the integrity label on the various processes under explorer.exe. Elevated processes run with a high integrity label and use the environment of the administrative user. For example, the registry hive HKEY_CURRENT_USER, as seen by an elevated process, will be the hive of the administrative user, not the standard user who initiated the elevation. This provides some protection against poisoning attacks.

Image from book
Figure 4-12: Elevated tasks run on the standard user's desktop.

Since the elevated applications still run on the standard user's desktop there is still not a separation of processes, and a non-elevated process can still interact with an elevated process. To achieve separation you would need to log out as the standard user and log on as the administrative user. You may also do this with fast user switching (FUS). Unlike Windows XP, FUS is enabled on domain-joined computers.

Special Topics in Elevation

Elevation is designed to be used programmatically, by developers, and in binary applications only. For instance, if you attempt to launch a registry script (REG), or vbscript (VBS), elevated, you cannot do so. You would have to launch an elevated command prompt, and then open the application from there. The option to "Run as administrator" is not present for REG and VBS files.

Using a simple registry hack, however, you can add the Run as administrator option to any file type you want. To do so you need to add a runas command to the registry entry defining the file type.

First, open the registry and search for the extension to the file type you wish to enable Run As for. For instance, you will find VBS files under HKEY_CLASSES_ROOT\.reg. Look at the default value in that key. It lists the file type name. In this case, it is regfile. Now search for regfile, and you will find HKEY_CLASSES_ROOT\regfile. Expand that key, and then expand the shell and open keys. Look at the default value of the open key. It should be regedit.exe“%1”. The command to elevate it is exactly the same, but you need to tell the shell to elevate the application parsing this file first. To do that, you add a runas key under the shell key and copy the same default value into it. Finally, you need to create a value called IsolatedCommand in the same location, and copy the same value to it.

This can be automated using a registry. For instance, here is a registry script that adds the Run as administrator context menu item to VBS and REG files:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\regfile\shell\runas\command]
@="regedit.exe \"%1\" %*"
"IsolatedCommand"="regedit.exe \"%1\" %*"
[HKEY_CLASSES_ROOT\VBSFile\Shell\runas\command]
@="WScript.exe \"%1\" %*"
"IsolatedCommand"="WScript.exe \"%1\" %*"

If you are interested in the syntax of these registry scripts, and much more, we warmly recommend the "Windows XP Commands" reference, at

http://www.ss64.com/nt/index.html.

New Privileges to Delegate Common Tasks

To meet the overarching goal of enabling more people to run as a non-admin more of the time, several things needed to happen. One of the most fundamental is the addition of some privileges.

Image from book
PRIVILEGES AND RIGHTS

Privileges and rights are not the same in Windows. Yet, because they are managed the same way, they are often thought of as the same thing with a different name. Under the hood, however, they are different.

A right is correctly referred to as an account right. It grants a subject the right to log on or not log on through a particular mechanism, such as logging on locally.

A privilege permits a subject to perform certain system-related operations, such as changing the system time zone.

Account rights and privileges are so separate, in fact, that they are actually defined in two different source code files. Account rights are defined in NTSecAPI.h, while privileges are defined in WinNT.h.

Both account rights and privileges have shortcuts that are used internally. You will often see these shortcuts used to denote the privilege. For instance, the right to log on locally is called SeLogonLocallyRight, and the privilege to change the system time zone is SeTimeZonePrivilege.

You will very often see rights and privileges referred to as one construct, usually under the moniker "privileges" and for the most part, there is little harm in doing so. We will take the approach that if we are taking about rights and privileges in general, we will call them "privileges." However, if we are speaking about a particular one we will use right or privilege, whichever is accurate.

Image from book

Windows Vista adds five new privileges, over Windows Server 2003. They are as follows:

  • SeTrustedCredManAccessPrivilege: "Access Credential Manager as a trusted caller." This privilege allows a subject to access the credential manager to back up and restore all the entries in it. Obviously, it should be granted very sparingly, if at all. By default it is not granted to any user. A few processes, such as WinLogon (the Windows logon application), smss.exe (Windows session manager), and lsass.exe (local security authority sub-system) have it by default.

  • SeRelabelPrivilege: "Modify an object label." This privilege gives a subject the ability to modify the integrity label on an object. It is extremely sensitive, and allows the holder to compromise the entire computer by modifying labels. It is also not granted to any users by default, but is carried by several processes, including: smss.exe, csrss.exe (client-server runtime process), lsass.exe, and lsm.exe (local session manager).

  • SeIncreaseWorkingSetPrivilege: "Increase a process working set." This privilege allows a user to increase the working set, the number of pages of memory, allocated to a process. This is an important part of UAC. It permits users to run applications that need to increase their working set at run time.

  • SeTimeZonePrivilege: "Change the time zone." The poster child of why you could not run as a limited user in Windows XP was that you “can't "even change the time zone." Way back in the days of the original release of Windows NT, Microsoft decided that modifying the system time was a privileged operation and should only be granted to administrators. This made sense because if you can change the system time, you can modify audit events. Try it some time: generate some audit events, then set the clock back a few hours, and generate some more events. The newest events will be on top of the log, but according to the timestamp on the events they occurred before the events that come after them. Changing the time zone, however, only changes the offset of the system time from Zulu time. This does not modify audit events because they are logged using Zulu time anyway. Thus, while changing the system time is a sensitive operation, changing the time zone is not. Yet, until Windows Vista, the same privilege, SeSystemtimePrivilege, governed both operations. In Windows Vista the code was factored and a new privilege, for changing the time zone, was added. Users have the SeTimeZonePrivilege, but only Administrators and LocalService have SeSystemtimePrivilege. The reason there is a privilege for this is so that the ability to change the time zone can be disabled. For example, when using parental controls, standard users no longer have the ability to change the time zone; this helps to avoid the situation where children change it to use the computer longer.

  • SeCreateSymbolicLinkPrivilege: "Create symbolic links." Windows Vista supports full symbolic links (symlinks), contrary to earlier versions of Windows which supported only junction points. Junction points are formed from the drive signature and are therefore persistent across drive letter changes, which is important. Junction points are designed to be used with systems where you have more than 26 volumes. However, they can only point to local resources. Symlinks can point to anything across the file system and the network. For instance, you can have a symlink pointing to a network share, as in this example:

    mklink /d foo \\server\share\directory
Image from book
UTC OR ZULU TIME

Zulu time is the phonetic representation of what more commonly is referred to as Coordinated Universal Time (UTC). The concept of time zones was commonly understood by sailors from early on; each time they traversed 15 degrees of longitude they entered a new time zone, offset by 1 hour from the previous one. Then, in the late 18th century Nathaniel Bowditch wrote the most famous book on navigation of all time: The American Practical Navigator. In his work on navigation, Bowditch designated all the time zones with a letter, starting with the time zone centered on east longitude 15 (now European Central Time), which was time zone A. When all the time zones were named, including the one straddling the International Date Line, which received different designations on either side, there was still one time zone left: the one centered on the prime, or the Greenwich, Meridian. That one received the last letter that was left: Z, which in phonetic spelling is "zulu" or sometimes today, "zebra." Times written as Zulu time commonly have a Z appended to them.

Greenwich Mean Time (GMT) was replaced by UTC as the world time standard between the 1960s and 1972. GMT is based on the rotation of the earth, while UTC is based on atomic clocks.

Internally, Windows keeps time in UTC. All time stamps, file times, and so on are measured in UTC. In fact, the event logs actually show that the events are created in UTC, or Zulu time. If you inspect the details of an audit event, you will see that the time is listed in Zulu time, as shown in Figure 4-13.

Image from book
Image from book
Figure 4-13: The Windows Event Log shows the times in the local time zone, but computes them from the internally stored UTC time.

Symbolic links have always been associated with certain security concerns. Not only people, but also software, may make security decisions based on where in the name space an object resides. For instance, if an administrator runs a tool that changes the owner or access rights on a folder hierarchy, and a malicious user has created a symbolic link inside that hierarchy, the security of the computer can be compromised if the tool evaluates the symbolic link and traverses somewhere else. A user might, for example, have a symlink inside a public directory that points to %windir%. If an administrator changes the permissions on the public directory to fix a problem, and the tool traverses the symlink, permissions would also be changed on %windir%. For this reason, the ability to create a symlink should be restricted to only certain trusted users. The SeCreateSymbolicLinks privilege is designed to allow delegation of the right to create symlinks.

Application Factoring

Another critical component of UAC is application factoring. Many applications required administrative privileges, even though the vast majority of users running the application did not use the functionality that required administrative privileges. By factoring out those components into either separate applications, or into separate tasks, an ordinary user can use the rest of the features of the application without having to be an administrator.

UAC introduces the concept of a "COM Elevation Moniker." Simply put, a COM Moniker leverages the Component Object Model (COM), a programming concept that allows developers to separate tasks into reusable components. By factoring out tasks requiring administrative privileges into separate components, a developer can permit a user to run much of an application without elevating, while easily allowing elevation when needed.

Consider the screenshot in Figure 4-14. Figure 4-14 shows a COM Moniker in Task Manager. When a non-administrator, or an administrator in admin-approval mode, launches Task Manager, it shows only that user's processes. To show processes from other users is an administrative operation. To do so easily Task Manager links the button "Show processes from all users" to a COM Moniker, which will launch an elevated instance of Task Manager, as shown in Figure 4-15.

Image from book
Figure 4-14: Task Manager uses a COM Moniker to allow users to use only a subset of the functionality without elevating.
Image from book
Figure 4-15: Task manager launched elevated

COM Monikers are heavily used in the operating system to factor functionality that requires administrative privileges while allowing the remainder of the application to be used without elevation. Note that the elevation happens within the same context though. This means that there is a potential for privilege leaks across a COM Moniker elevation. Again, this is further reason to run as a standard user most of the time.

Virtualization

For good and bad, there are thousands of applications already out there for the Windows platform. Far too many of them are designed, written, and tested under the assumption that the user running them will be an administrator. The most common reason why these applications do not work as an non-admin is that they try to write to protected areas of the computer-areas that only admins have access to.

To make applications that exhibit only these types of flaws work under a non-admin user on Windows Vista, the OS gives them access to a virtual copy of certain parts of the computer. %programfiles%, %systemroot%, and portions of HKEY_LOCAL_MACHINE\Software may all be virtualized for applications that need it. To find out if a specific registry location can be virtualized, check the value of the REG_KEY_DONT_VIRTUALIZE flag using the reg.exe flags command. In our testing, we found there are 4,803 keys in the registry that permit virtualization but the total number may vary depending on what you have installed. If a registry key has its flag set to True, or Empty, it cannot be virtualized. One potential issue with virtualization happens when you edit the registry on a Windows Vista system with a Windows Server 2003 or Windows XP system. These systems do not support the flags, and will clear them. This means that virtualization will fail for all keys that were edited on a down-level system.

Virtualization is not something applications ask for. Legacy applications get it if they request to write to places they should not. Virtualization is enabled automatically for 32-bit applications run by interactive users. No other applications are virtualized. If an application attempts to write to a file in a virtualized location, the file will actually be stored in %userprofile%\AppData\ Local\VirtualStore\. That means that all virtualized applications of a particular user will see the same virtual stores, but virtualized apps run by another user do not see the same changes.

Note here that virtualization only happens if an application attempts to write to a location that it does not have access to. If an application never writes to any of the potentially virtualized locations, there is no virtualization happening. Likewise, before attempting to read or write to a location that can be virtualized, the OS checks to see if there is a virtual copy already. If there is, the OS uses the virtualized copy and does not even attempt to use the actual location.

Virtualization is considered a "temporary" feature by Microsoft. It is available only to provide compatibility for older applications until they are updated. The plan is to remove virtualization in a future version of Windows.

Integrity Labels and Low Rights Apps

Integrity labels are discussed in several places in the book. They are a mandatory integrity control (MIC) mechanism, similar to that proposed by Biba in 1975. A non-elevated process typically has a medium integrity label. Likewise, objects that are not specifically marked with an integrity label are considered medium integrity. Accordingly, it can read and write only medium integrity and lower data. An elevated process receives a high integrity label. A process cannot write to an object with a higher integrity label. Therefore, a non-elevated process cannot write to objects, such as memory, owned by an elevated process.

Some processes receive a low integrity label. Currently, this is used only by IE. IE is also the only built-in process that marks objects it saves with an integrity label. This prevents IE from writing to almost all objects on the computer. This is part of what is referred to as "Protected Mode," which you may have noticed in the status bar of IE if you run it on Vista. The intention is that several other exposed user applications, such as MSN Messenger and parts of Office, will eventually run with low integrity labels as well.

Even objects created during setup of the OS or an application do not get an integrity label stamped on them by default. Doing so would create problems. For example, a setup process for a game may create a file to hold high scores. If that file were marked with high integrity (the label of the setup process), the game itself, running in medium integrity, would be unable to write to it.

Note that if you disable UAC you also disable protected mode in IE. Disabling UAC and running IE as an administrator means that you have essentially the same level of exposure as in Windows XP. Disabling UAC and running IE as a standard user means that exploits coming in through IE can corrupt any location in the user's profile.

Special Treatment of Built-in Administrator

As part of UAC, Windows Vista modifies how the built-in Administrator account, RID 500, is treated. On a clean installation of Windows Vista the builtin Administrator is disabled.

During an upgrade the disposition of the built-in Administrator account depends on the disposition of the account at the start of the upgrade and the status of other administrative accounts on the computer. If the built-in Administrator account is the only enabled, local account in the Administrators group that is allowed to log on locally, it is left enabled and placed in admin-approval mode. If other active local administrative accounts exist, the built-in Administrator account is disabled.

The built-in Administrator account is also treated specially in safe mode. Table 4-1 summarizes when the account can be used to log on in safe mode.

Table 4.1: Treatment of Built-In Administrator in Safe Mode Open table as spreadsheet
COMPUTER STATE | BUILT-IN ADMINISTRATOR STATE | OTHER LOCAL ADMINS AVAILABLE | LOGON WITH BUILT-IN ADMINISTRATOR IN SAFE MODE?
Standalone | Enabled | Does not matter | Yes
 | Disabled | Yes | No
Domain joined | Disabled | Does not matter | No
 | Enabled | Does not matter | Yes

The special treatment of the built-in Administrator account means that organizations must put a little more planning into recovery to ensure that if they decide to use safe mode, there is an account available to log on with. On the plus side, the long-standing physical access exposure of the default blank password on the built-in Administrator account in Windows XP is now gone.

No More Power Users

Power Users were introduced early in the Windows NT history. The idea was to create a group that had enough privileges to perform certain sensitive operations on the system, but that were not true administrators. As good an idea as this was, it never worked. Power Users are administrators that have not made themselves administrators yet. It takes milliseconds for an exploit to elevate from a Power User to an administrator. Many people inside Microsoft called Power Users "admins lite."

It is no wonder then that the Power Users group was almost entirely deprecated in Windows Vista. Power Users have almost no privileges and permissions by default. There are a few straggling positions left over by accident, and those will be gone soon as well. It is likely that in the next version of Windows, Power Users will be entirely gone.

The reason Microsoft did not remove the Power Users group entirely in Windows Vista is that many organizations put their users in that group. Those organizations may have granted additional permissions to that group and if Microsoft were to remove the group entirely those organizations would pay a huge cost to transition their permissions. Therefore, the best option was to remove all the default permissions.


UAC and Remote Access

UAC also impacts certain types of remote access to a computer running Windows Vista. Exactly how differs between access methods and account types.

SMB Access

Windows Vista can, as all previous versions of Windows, act as a server for Server Message Block (SMB) sharing. Connecting to a computer running Windows Vista that is acting as a server while using domain accounts for authentication will work exactly as in Windows XP. If the domain account is a local administrator, the impersonation token used on the server to perform access checks is a full administrative token. However, if you authenticate with a local account that is a member of the Administrators group, you will get a filtered token, just as if you were logging on locally with that account. The difference, of course, is that in the SMB case, you cannot elevate.

The reason tokens are filtered in stand-alone environments is to stop a worm from propagating over network connections. Malware that infects one computer and becomes an administrator there could spread to a different computer if that computer has an administrative account using the same user name and password. However, if administrators get a filtered token when they connect, the exploit will likely fail. Computers in a domain environment do not get a filtered token because it would break too many remote management tools.

This behavior can be changed using a registry hack:

Hive:    HKEY_LOCAL_MACHINE
Key:     SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system
Value:   LocalAccountTokenFilterPolicy
Type:    REG_DWORD
Data:    0 (default) - Build filtered token
         1 - Build elevated token

You can add this setting to the Group Policy Security Options interface by using the technique documented in Microsoft Knowledge Base Article 214752. On the Web site for the book you will find an updated sceregvl.inf file that contains the new setting.

Remote Desktop and Remote Assistance

Remote Desktop, also known as Windows Terminal Services, works just like an interactive session for the purposes of UAC elevation. Remote Assistance (RA), however, poses certain new challenges.

RA is a feature first included in Windows XP. It allows an "expert" to assist a user in troubleshooting by opening a remote connection to a user's logon session and interacting with that session. This permits the user to very easily show the expert what is happening.

UAC has an interesting side effect on RA. The prompt shows up on the secure desktop, but the secure desktop is not available over RA. The end user that is being helped can answer the prompts, but not if the end user is not an administrator and does not have credentials for an administrator. In this case, the only option is to disable the setting to show the UAC prompt on the secure desktop. To do so, you may set this registry key:

Hive:    HKEY_LOCAL_MACHINE
Key:     SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system
Value:   PromptOnSecureDesktop
Type:    REG_DWORD
Data:    0- Elevation prompt goes on the
1 (default) - Elevation prompt goes on the secure desktop

You would need to make this change before establishing the remote assistance session. This can be done using the following command line command:

reg add \\<remote computer name>\HKLM\SOFTWARE\Microsoft\Windows\  Image from book  CurrentVersion\Policies\system /v PromptOnSecureDesktop   Image from book  /t REG_DWORD /d 0 /f

You would need to replace < remote computer name > with the name of the remote computer you are connecting to. After you are done with your RA session you can revert the system to its original state using this command:

reg add \\<remote computer name>\HKLM\SOFTWARE\Microsoft\Windows   Image from book
\CurrentVersion\Policies\system /v PromptOnSecureDesktop   Image from book
/t REG_DWORD /d 1 /f

This setting is also available in Group Policy. See the section "UAC Policy Configuration" for information.

If the policy is set to deny elevation requests for non-administrator, the elevation will be denied automatically and no prompt is ever shown. In that case, that policy needs to be turned off before launching the RA session. Alternatively, the expert can launch an administrative command prompt using the runas.exe command as an administrator. This command prompt will be running with a filtered token, but now the elevation is subject to the elevation policy for administrators, not users, so the prompts will be shown, subject to the policy on where to put them. Keep in mind, if you use this approach, that if the user requesting help pulls the network cable from the computer at this point, the user is left with an administrative command prompt running as someone else.


UAC Policy Configuration

UAC can be configured with nine different group policy settings (ten if you add the one we discussed previously). This section covers each setting and our recommendation for how to use it.

User Account Control: AdminApproval Mode for the Built-in Administrator Account

This setting controls whether or not to build a filtered token for the built-in Administrator account. By default the setting is disabled, which means that the built-in Administrator account always logs on with a full administrative token. Note that this setting has no bearing on whether the built-in Administrator account can be used or not. If the built-in Administrator account is disabled, its logon ability is controlled as we mentioned previously. This setting only controls how the token is created if the account is allowed to log on.

We recommend that you ensure that the built-in Administrator account is disabled and not used. If you do, this setting will not matter.

User Account Control: Behavior of the Elevation Prompt for Administrators in Admin Approval Mode

By default, all administrators, except for the built-in Administrator account, are in admin-approval mode. Also by default, they get a consent prompt when they try to execute an administrative task. This setting changes whether they get a consent prompt or not. If this setting is set to "Elevate without prompting," the elevation is automatic. This means that the user is never prompted for elevation. This setting may be used in environments that wish to turn off UAC. The reason is that it gets rid of the prompt, but retains the other benefits of UAC, including the low-rights Internet Explorer. If UAC is disabled, entirely low-rights IE no longer works either. As a result, the relatively weak process isolation that existed between administrative and non-administrative processes is completely removed.

The third option in this setting is to prompt for credentials. This makes the elevation prompt behave the same for administrators and non-administrators.

We recommend that you leave the default setting.

User Account Control: Behavior of the Elevation Prompt for Standard Users

This setting is used to bar elevation for standard users. The options are "Prompt for credentials" and "Automatically deny elevation requests." The latter option is used in environments where you wish to provide no avenue for elevation at all for standard users. Note that if you configure this to deny elevation requests, you will break many Remote Assistance scenarios, as outlined previously.

We recommend that you leave this setting at its default. Your site security policy and risk management philosophy should govern whether you provide users with administrative credentials or not. We will point out, however, that you may want to consider the cost of a helpdesk call in this decision. If you leave the setting at its default and your users are standard users, they will effectively be told to call the helpdesk each time a web page asks to install an ActiveX control. If you configure this setting to "Automatically deny elevation requests," they will be told, essentially, that the policy is stopping them from doing something. This latter option may result in fewer helpdesk calls.

User Account Control: Detect Application Installations and Prompt for Elevation

This setting enables heuristic detection of installers. UAC has been programmed to detect the most common application installers and automatically prompt for elevation when one of them is launched. It is set to be enabled by default. Organizations that wish to, may set it to disable, which will have the effect of disabling most installers as they more or less universally require admin privileges.

This setting has a minimal impact on security. If a user does not have administrative privileges, this setting has no impact anyway.

Note that the explanation for this setting indicates that it is set to Disabled in the enterprise. This is not correct.

User Account Control: Only Elevate Executables that Are Signed and Validated

This setting can be used to disable elevation of unsigned executables. Doing so may be worthwhile, but will break a substantial number of existing applications. Therefore, it is turned off by default.

We recommend that you evaluate your risks and the applications you run. If you can get away with breaking unsigned applications you should, but doing so will cause significant pain for users. If you have the ability to do so, you can sign everything that you want elevated, turn this setting on, and then configure silent elevation. That will effectively get rid of all UAC prompts, but at the cost of a lot of work signing applications.

User Account Control: Only Elevate UIAccess Applications that Are Installed in Secure Locations

Applications may be configured to allow User Interface access (UIAccess) from applications with lower privileges. This permits an application running with a standard user or filtered admin token to programmatically drive UI for an app running with a full administrative token on the same desktop or to send window messages to applications on the secure desktop. Permitting this opens a substantial security hole. Therefore, this setting allows you to control, to some extent, which applications can do this. By leaving this setting at enabled, which is the default, only applications in %ProgramFiles% and %SystemRoot% may launch with UIAccess turned on. This, presumably, limits it to applications that are trusted and installed in trusted locations.

We recommend that you leave this setting at its default: enabled.

User Account Control: Run All Administrators in Admin Approval Mode

This setting disables UAC entirely. Its name is a bit misleading, indicating that UAC is still there, but if this setting is set to disabled, all UAC behavior functions the same way it did in Windows XP. This means, for example, that if an administrator launches IE, it will launch with a full administrative token.

We recommend you leave this setting at its default: enabled.

User Account Control: Switch to the Secure Desktop when Prompting for Elevation

This setting was discussed previously. Setting it to disabled causes UAC prompts to show up on the user's desktop instead of the secure desktop. This permits applications to more easily spoof the prompts and even drive input to and from them.

We recommend that you leave this setting at its default: enabled.

User Account Control: Virtualize File and Registry Write Failures to Per-User Locations

We discussed virtualization earlier. This setting can be used to disable virtualization system wide. Doing so will cause applications that request write access to protected locations to fail just like they did in Windows XP.

We recommend that you leave this setting at its default: enabled.


Frequently Asked Questions About UAC

Having worked with Windows Vista for quite some time now, and monitoring the forums where people ask questions, we find that the same set of questions are asked over and over again about UAC. To streamline this process a little we thought we would answer most of them here as many readers will probably have the same questions.

Why Can't I Access My Files?

This question is usually accompanied by some explanation, of varying degrees of clarity, that the author wants to delete or modify a file in %ProgramFiles% or %SystemRoot%. Alternatively, the user is trying to modify a file that Administrators have access to. Consider this scenario: Let's say we have some file that looks as follows:

C:\Users\test>icacls foo.txt
foo.txt NT AUTHORITY\SYSTEM:(F)
        BUILTIN\Administrators:(F)

We are logged on as a member of the Administrators group:

C:\Users\test>whoami
jj-vistartmtst\jesper
C:\Users\test>net localgroup administrators
Alias name     administrators
Comment        Administrators have complete and unrestricted access
to the computer/domain
Members
------------------------------------------------------------------------
Administrator
Jesper
The command completed successfully.

If you try to delete this file, however, you get the following response:

C:\Users\test>del foo.txt
C:\Users\test\foo.txt
Access is denied

At this point the user frequently launches into a rant about "tyrannical operating systems" that "block me from doing what I want with the software I have bought and paid for …"

Ignoring the rant for a moment, the answer to why you cannot delete this file should be relatively obvious. With UAC enabled, even members of the Administrators group have a token that has the Administrators SID set to disabled. In other words, Administrators have full control over the file, but you are not an administrator, yet. To access this file you must elevate. You can do that by launching an elevated command prompt, or by changing the ACL on the file, and using the COM Monikers in the ACL UI to elevate. You cannot, however, elevate an Explorer window, which brings us to our next question.

Why Can't I Delete Stuff If I Elevate Windows Explorer?

So, in frustration over the "tyrannical operating system" the user now elevates an instance of Windows Explorer. He right-clicks on Windows Explorer (see Figure 4-16).

Image from book
Figure 4-16: Right-click on Windows Explorer.

Then he goes through the elevation motions … (see Figure 4-17).

Image from book
Figure 4-17: Attempting to elevate Windows Explorer

An Explorer window pops up, and he attempts to delete the file (Figure 4-18), and the following dialog box shows up:

Image from book
Figure 4-18: Attempting to delete a protected file from an "elevated" Explorer window

At this point various colorful language and threats of physical violence ensues. Yet, the problem is quite simple. Recall that we said earlier that you cannot elevate explorer.exe! Each user can have one and only one instance of explorer.exe, and you have one running your desktop already. Therefore, elevation of explorer.exe is barred, even though the OS for some reason lets you go through the motions of trying. If you inspect the token for your "elevated" explorer.exe you will find that it, in fact, never launched a new instance of explorer.exe after all. It is just another window to the same instance that is still running with a filtered token.

This behavior becomes even more interesting when the user tries to delete or modify some part of the OS. For instance, let's say the user has decided that Internet Explorer really offends him for some reason, so he tries to delete it.

C:\Windows>del "c:\Program Files\Internet Explorer\iexplore.exe"
c:\Program Files\Internet Explorer\iexplore.exe
Access is denied.

This is easily explained. Administrators only have read-access to operating system files:

C:\Windows>icacls "c:\Program Files\Internet Explorer\iexplore.exe"
c:\Program Files\Internet Explorer\iexplore.exe NT SERVICE\TrustedInstaller:(F)
                                            BUILTIN\Administrators:(RX)
                                            NT AUTHORITY\SYSTEM:(RX)
                                            BUILTIN\Users:(RX)
Successfully processed 1 files; Failed processing 0 files

To modify the ACL you would first have to change owner of the file. The icacls tool also allows you to set the owner of a file, but due to what is likely a bug in the original release of Windows Vista, it cannot solve this particular prob lem because Administrators do not have permission to change the owner on protected files. An elevated token does contain the SeTakeOwnershipPrivilege, but it is disabled. Icacls does not enable it before attempting to change the ownership. Therefore, icacls cannot be used to take ownership of protected OS files. To work around this you can either take ownership in the GUI, or use the takeown.exe tool to change the owner. Once you own the file you can modify its ACL and grant yourself permission to delete it.

How Do I Disable UAC?

If you want to disable UAC entirely you can do it a couple of different ways. If you want to do it on a single system, you can do so with the User Accounts control panel applet, as shown in Figure 4-19.

Image from book
Figure 4-19: You can turn off UAC with the User Accounts control panel applet.

If you need to turn off UAC on a whole fleet of computers the easiest option is to use Group Policy. The setting that governs UAC is the "User Account Control: Run all administrators in Admin Approval Mode" setting. If you set it to Disabled, you turn off UAC. Doing so requires a reboot.

What Happens If I Turn Off UAC?

If you turn off UAC you need to remember that you lose all the protection it affords, including Internet Explorer Protected Mode. Internet Explorer now runs with the same rights as it did in Windows XP, which means that, if you are logged on as an admin, one bad click can compromise your entire system. You do not just lose the prompts if you disable UAC. This is why we recommend that if you dislike the prompts you should enable automatic elevation instead to retain at least some of the protection UAC gives you. Of course, if you have to click an inordinate number of prompts you might also want to consider what you are doing with this computer because in day-to-day use we rarely see any elevation prompts at all. We highly encourage you to leave it on for a couple of weeks. You will likely have a decreasing number of prompts over time.

What Access Do Low Processes Have to High Processes?

The short answer is, very little without taking hostile action. The slightly longer answer is that it depends on how the high-integrity process is executed. Earlier we discussed the UIAccess flag. Setting this flag enables a low-integrity process to use the SendMessage() API to send window messages to a high-integrity process. If the flag is not set on the process, then most messages are filtered.

It is interesting to note that the Logon SID has Read Memory rights to elevated processes. However, even though a process running with a filtered token has the same Logon SID it does not have the right to read memory. The reason is that the integrity controls in Windows Vista do not follow a strict Biba model. In the Biba model a lower integrity process could read higher integrity data but not write it. Biba is a "read up, write down" model. The Windows Vista integrity model permits only "read down, write down."

This means that the only legitimate access a process running with a filtered token has to a process running elevated is the ability to query limited information and to use the elevated process for synchronization. This corresponds to the PROCESS_QUERY_LIMITED_INFORMATION and SYNCHRONIZE flags. PROCESS_QUERY_LIMITED_INFORMATION is a new right flag with Windows Vista which allows you to query for the full name of the executable image that was used to launch the process.

It is really important to note, in this context, however, that UAC was never designed to establish a security boundary between processes on the same desktop. Therefore, there will always be ways for a malicious process to interact in undesirable ways with an elevated process on the same desktop. This is simply a design limitation of UAC. Recall from the goals we mentioned earlier that process isolation was not a design goal of UAC. Do not rely on UAC to keep you safe from malicious code.

Why Does the Screen Have to Go Black?

The screen goes black, or more correctly, a transparent black, when the OS presents a UAC elevation prompt on the secure desktop. As we discussed, elevation prompts are shown on the secure desktop to prevent tampering with them by unelevated processes on the user's desktop. The secure desktop does not permit programmatic access. Therefore, for sensitive tasks, such as credential entry and UAC, the secure desktop permits a measure of process isolation. This behavior can be disabled using the "User Account Control: Switch to the secure desktop when prompting for elevation" group policy security setting. If it is disabled the prompts are shown on the user's desktop instead, but this significantly reduces the security of the elevation process and we recommend you leave the default turned on.

Some users have complained of significant delays in this switch to the secure desktop. These are most likely caused by driver issues with the video card. It is also possible that they can be caused by a very slow video chip. With even moderately speedy hardware, such as that found in a standard-issue corporate laptop, the delay is minimal.

I Don't Need UAC; Can I Just Enable It for Other Users?

No, you cannot enable UAC per user. UAC is a system-wide setting, and quite frankly, we believe that everyone can benefit from UAC. This is particularly true if one considers that the ability to run exposed processes, such as Internet Explorer, in a protected sandbox disappears if you disable UAC.

If you absolutely cannot stand UAC you can enable automatic elevation for admins in admin-approval mode using the "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" group policy security setting. However, you need to realize that when you do that any malware you run, whether by accident or intentionally, has full access to your computer. Therefore, we highly recommend you do not enable automatic elevation and develop a way to work with UAC that allows you to retain your level of protection. One method that does work well for some users is to enable automatic elevation for admins and then use two accounts. One account is a standard user and is used for day-to-day tasks. The other account is an admin and is used for admin operations. While reading e-mail and surfing the Web, use the standard account. When you need to perform an administrative task you can use FUS, as shown in Figure 4-20, to switch to the administrative account. Windows Vista supports FUS even in domain-joined situations, contrary to Windows XP.

Image from book
Figure 4-20: Windows Vista supports Fast User Switching even on domain-joined computers.

What About Remote Access?

Remote access via Windows Networking (SMB) is primarily impacted on stand-alone computers, as mentioned earlier. On domain-joined computers remote access using SMB works exactly like Windows XP. To turn off the generation of filtered tokens for remote access with local administrative accounts on a stand-alone computer, set the LocalAccountTokenFilterPolicy registry key as shown earlier.

Why Isn't UAC More Like Sudo?

A very common complaint from those familiar with Unix is why UAC couldn't be more like sudo. For the uninitiated, sudo is a method in Unix to run commands as a different user, typically the root user (equivalent to the built-in Administrator in Windows). An administrator uses a file called sudoers.conf to define which commands may be executed by which users. As long as a user is permitted to run a particular command in that file the user may type sudo<command> in any command shell and the command will execute as root.

Sudo has proven very long-lived. Used properly, it provides a convenient and very sensible way to elevate particular tasks. Used poorly, it makes every sudoer root. We find that the poor implementation is far more common.

In a sense, sudo provides a convenient way to become root for a particular task. This is actually one of the primary reasons why sudo is quite different from UAC. The purpose of sudo is simply to allow a non-root user to run a root command. The purpose of UAC is much more than to allow users to become omnipotent for particular tasks. As we discussed above, UAC is first and foremost about allowing more users to do more things without being omnipotent at all. Unix was originally designed to permit that, but Windows has been suffering from a legacy of operating systems without any security model at all for almost 20 years now.

It is also important to keep in mind that when building UAC, Microsoft took the quite sensible approach that it was better to build something that leveraged the strengths of the Windows architecture than to build something that was designed for the Unix architecture. The two technologies, therefore, are similar, but at the same time, very different.

Sudo has a great advantage over UAC that it can theoretically restrict access to only certain commands. UAC does not permit an administrator to delegate a specific command to a user. On the other hand, in practice, this function is relatively rarely used as it becomes very cumbersome, and many of the commands that would be delegated indirectly confer administrative rights on the user anyway. For instance, if the administrator delegates editing of a cron job that runs as root to a non-admin user, that non-admin user can easily become root by editing the cron job. In UAC, Microsoft instead tried to enumerate all the commands that could confer admin rights, and require a UAC elevation for those. Of course, Microsoft did not achieve a complete enumeration, so there remains a large number of tasks that are quite innocuous, but which require elevation. For instance, access to the registry editor requires elevation if the user is a split-token administrator, even though large parts of the registry cannot be used to elevate privileges.

Sudo also is very good because it allows delegation to individual users without making them administrators. A user can be granted the right to perform a single task. To do the same in Windows Vista, the user would have to either be a member of the Administrators group, or be provided with the password of a member of the Administrators group. This is perhaps the greatest benefit to the sudo approach versus UAC. With UAC, the user must be granted effectively unfettered access to the system to be able to elevate even a single task. Sudo, by contrast, allows creation of effectively custom administrators. Of course, from a realism perspective, there is a really good chance that they all become effective administrators after you are done. To be totally pragmatic, Microsoft's approach of making their administrative status so obvious is appropriate when faced with the choice of hiding it behind a lot of seemingly innocuous commands.

On the other hand, sudo was designed for a Unix command line environment, not a Windows GUI environment. UAC was designed to take advantage of the environment it was being used in, and manages to do so quite well. In addition, sudo is vulnerable to attacks from malicious programs run as a non-elevated user. For instance, if a user has sudo rights to a sensitive program, like a shell, then another program that the user executes could call sudo and now have privileged access to the operating system. It is a well-recognized fact in the Unix/Linux community that if an attacker gains access to an account from which you run sudo to perform administrative tasks, the attacker has won. This, of course, is exactly the same in Windows.

Taking advantage of the GUI environment in Windows, UAC, by default, switches to the secure desktop for the elevation prompt. This makes interference attacks from processes that run on the user's desktop much more difficult, although not by any means impossible. Some consider the prompt extremely annoying, but it is an integral part of the security of UAC. The secure desktop does not permit its interface to be driven programmatically. Therefore, a malicious program executing in the users non-elevated context cannot programmatically invoke an elevation and respond to the prompt. As long as the secure-desktop switch behavior of UAC is not disabled, this provides a reasonable degree of assurance that the user intended to elevate.

Sudo does also have some benefits that UAC simply cannot match. First, it provides far better logging than UAC. In the following section we discuss how to audit elevation events. With sudo, however, you can audit much more than just the elevation itself. You can audit more or less everything the user did after the elevation. Of course, if an attacker has sudo rights to certain commands the attacker can tamper with the syslog and interrupt the event flow.

Sudo also permits definitions of hosts, IPs, host classes, and so, in which sudo is valid. This can be used to allow a user to execute remote commands as a different user, but only on particular hosts. Windows and UAC simply have no counterpart to that.

Finally, sudo has a system that permits caching of the credentials for a period of time, by default, 15 minutes. This means that the user does not have to re-enter the password for the target user when elevating another task within 15 minutes of the last elevation. This, however, is actually a security risk. If a malicious application is running on the system, or manages to run within the same controlling terminal that you executed the elevation in, the malicious application could elevate without further user input. To avoid this type of attack, Microsoft did not build functionality to cache passwords entered for elevation.

How Do I Audit Elevation?

One area where UAC definitely falls behind technologies with similar functionality, such as sudo, is in auditing. To turn on auditing for UAC elevation you need to configure both success and failure auditing of process tracking. Unfortunately, this is one of the noisiest audit categories in Windows. A single UAC elevation causes around 10 events with IDs 4688 (Process Creation), 4696 (A primary token was assigned to a process) and 4689 (Process Termination).

Note

Event numbers in Windows Vista have changed from those in Windows XP. Many of the events have additional information in them, and consequently have a different structure than they did in Windows XP. Event log management systems typically key off the event ID and the source to determine how to parse the event. If the structure of an event changed, but the source and event ID remained the same, it is highly likely that many event log management systems would encounter severe problems parsing the events. Therefore, the events that were modified were renumbered. To find the new number of your favorite event from Windows XP, take the Windows XP event number and add 4,096 to it.

To determine which process was elevated and as which user, you need to correlate two events: 4688 and 4696. For each process that was elevated you will find one event 4688 that shows you which process was created. The process, however, is initially created under the LocalSystem account, as shown in this event:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          1/12/2007 6:57:28 PM
Event ID:      4688
Task Category: Process Creation
Level:         Information

Keywords:      Audit Success
User:          N/A
Computer:      JJ-VistaRTMTst
Description:
A new process has been created.
Subject:
    Security ID:           SYSTEM
    Account Name:          JJ-VISTARTMTST$
    Account Domain:        WORKGROUP
    Logon ID:               0x3e7
Process Information:
    New Process ID:            0x9f8
    New Process Name:      C:\Windows\System32\cmd.exe
    Token Elevation Type:  TokenElevationTypeFull (2)
    Creator Process ID:     0x5b4
Token Elevation Type indicates the type of token that was assigned to
the new process in accordance with User Account Control policy.
Type 1 is a full token with no privileges removed or groups disabled.
A full token is only used if User Account Control is disabled or if the
user is the built-in Administrator account or a service account.
Type 2 is an elevated token with no privileges removed or groups
disabled.  An elevated token is used when User Account Control is
enabled and the user chooses to start the program using Run as
administrator.  An elevated token is also used when an application is
configured to always require administrative privilege or to always
require maximum privilege, and the user is a member of the
Administrators group.
Type 3 is a limited token with administrative privileges removed and
administrative groups disabled.  The limited token is used when User
Account Control is enabled, the application does not require
administrative privilege, and the user does not choose to start the
program using Run as administrator.

Note the Token Elevation Type and the associated description below. Events with TokenElevationTypeFull indicate a process that was created during a UAC elevation.

To find out which user account was used in the elevation, look for an event 4696 that has the same process ID as the New Process ID field in the 4688 event. This event is shown here:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          1/12/2007 6:57:28 PM

Event ID:      4696
Task Category: Process Creation
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      JJ-VistaRTMTst
Description:
A primary token was assigned to process.
Subject:
    Security ID:         SYSTEM
    Account Name:        JJ-VISTARTMTST$
    Account Domain:          WORKGROUP
    Logon ID:             0x3e7
Process Information:
    Process ID:           0x3f8
    Process Name:        C:\Windows\System32\svchost.exe
Target Process:
    Target Process ID:    0x9f8
    Target Process Name: C:\Windows\System32\cmd.exe
New Token Information:
    Security ID:         SYSTEM
    Account Name:        Jesper
    Account Domain:         JJ-VistaRTMTst
    Logon ID:            0x15ef5

This event shows us that the system assigned a new token for the user JJVistaRTMTst\Jesper to this process. This happens before control of the process is handed over to the user but demonstrates that the process is actually launched by the system, not by the user.

Only by combining these two events can we tell (a) that a process was created and (b) which user it was created as. Note that we still cannot tell which user initiated the elevation. This functionality does not exist in Windows Vista, unfortunately.


Leveraging User Account Control in Applications

Programmers no doubt will wish to leverage UAC in applications, and even system administrators often do some programming in their daily jobs. This section is not meant as a complete introduction to how to use UAC in your applications but rather to give some ideas to system administrators to help them perform their tasks more easily. We also hope to give you a slightly better understanding of why UAC behaves the way it does in some situations.

Developers wishing more information on UAC are directed to books specifically targeted for developers on Windows Vista.

Application Manifests

The primary way to control UAC in applications is through the use of application manifests. An application manifest contains XML metadata about an application. These manifests are typically embedded within an application and are created when the application is built.

UAC is controlled by using a label called requestedExecutionLevel. There are two parameters in this attribute:

<requestedExecutionLevel
      level="asInvoker|highestAvailable|requireAdministrator"
      uiAccess="true|false"/>

The level attribute defines how the application should behave. If the level is set to asInvoker the application runs without any elevation. In other words, for both standard users and admins in admin-approval mode, it would run with a standard user token.

If the level is set to highestAvailable, the application will run with the highest privileges the current user can have. This attribute is the reason why some applications, such as regedit.exe, require elevation when run from an admin in admin-approval mode, but not when run by a standard user. The standard user can never become more than a standard user. Therefore, the highest available run level is what the user has already-standard user. The admin in admin-approval mode can become a full admin, and therefore, the highest available run level requires an elevation.

highestAvailable can cause some very strange user experiences. While some users get a consent prompt, others get no prompt at all and the application just launches. The application, however, is restricted even though no user interface component informs the user of that. Some users get a credential prompt instead. Overall, the experience is confusing. Therefore, highestAvailable should be considered an application compatibility mitigation that should be used sparingly.

Finally, we have the attribute requireAdministrator. This is used for applications that require administrative permissions to run and will cause an elevation prompt (if this functionality is enabled) for all users.

The second parameter to requestedExecutionLevel is the uiAccess attribute. If this attribute is set to false then applications on this desktop with a filtered or standard user token may not send window messages to an application with an admin token. If the attribute is set to true then this application will send window messages to applications running at higher privilege levels.

Elevating Installers

Elevating installers properly tends to be a task that is not as straightforward as it seems it should be. Robert Flaming, Program Manager on Windows Installer, has written a series of 27 blog posts on how to integrate UAC and MSI at

http://www.blogs.msdn.com/rflaming/archive/2006/09/20/763945.aspx. This series is well worth reading for anyone that needs to build installers. Perhaps the most important takeaway is that all installers should be marked with requireAdministrator. The OS will attempt to guess whether an installer needs it, but it is just a guess, and it is not always accurate. Unfortunately, the OS will also not give the user an option to attempt to run installers as a nonadmin. As soon as it detects that the program is an installer it always prompts for elevation.

Elevating in Scripts

Many IT professionals spend much of their day writing scripts. A common question is how to cause something inside a script to be elevated. This can be done by using the runas invoke verb in your script. Here is a sample script that launches an elevated command shell:

Set myShell = CreateObject("Shell.Application")
Set myFolder = myShell.Namespace("c:\windows\system32")
Set myFolderItem = myFolder.ParseName("cmd.exe")
myFolderItem.InvokeVerb "runas"

The Elevate Tool

The runas verb can also be used in calls to the ShellExecuteEx API. Without going into complete details on how this works, the runas verb is used to specify that the application should be elevated.

Because we always thought the ability to invoke an elevation from the command line was a useful feature that Microsoft omitted in Windows Vista, we used the runas verb and the ShellExecuteEx API to write a small application that can be used to elevate any command from the command line. The elevate.exe application is available on the Web site associated with the book. Using it is quite simple, as Figure 4-21 shows.

Image from book
Figure 4-21: You can use the elevate.exe application to elevate any application from a command line.

Elevated Command Prompt

One of the most useful tips if you need to perform many administrative tasks is to open an elevated command prompt and launch many of your applications in there. Any application launched from an elevated command prompt (except for ones that explicitly cannot be elevated, such as explorer.exe) are launched elevated.

Using the elevate.exe tool mentioned earlier, you can get an elevated command prompt by just right-clicking. Add this text to a registry script:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\ECmdHere]
@="Elevated Command Prompt Here"
[HKEY_CLASSES_ROOT\Directory\shell\ECmdHere\command]
@="elevate.exe cmd.exe /k cd \"%1\""

Import that script into the registry and put elevate.exe somewhere along the path. Now when you right-click on a folder, you get see an entry like the one in Figure 4-22.

Image from book
Figure 4-22: With the elevate.exe tool, it is easy to get an elevated command prompt anywhere.


Summary

UAC is a radical departure from earlier versions of Windows. Its main purpose is to enable more users to run more applications without being an administrator, and to simplify becoming an administrator when needed. While it is not perfect by any stretch of the imagination, we believe UAC is quite usable for the majority of users. Both the authors run with UAC enabled, and on many of our systems we run as standard users. We find that unless you routinely run tests and try to reconfigure your systems, you can go days, maybe even weeks, in normal operations without seeing a UAC prompt. Many information workers and home users will rarely see them once the system is stable.

We encourage everyone to give UAC a try. If you absolutely cannot stand it, turn off the prompting for admins in admin-approval mode and see if that helps. At least that way you retain some of the benefits from UAC.


Best Practices

  • Best practices for UAC can be summed up quite simply as follows:

    • Good: Run in admin-approval mode

    • Better: Run as standard user and elevate to a separate admin account

    • Best: Run as standard user and switch user to a separate admin account

  • Don't trust the vendor when they say their app must run as an administrator! One of the most visible, and egregious examples of where this is not true is in Microsoft's Visual Studio 2005 Service Pack 1. When you launch Visual Studio, it tells you that you should run it as an administrator. This is only true for some developers that need to perform certain tasks. More information is available at http://www.msdn2.microsoft.com/en-us/vstudio/aa972193.aspx.

  • Make sure that all your information workers, and everyone in your family run with UAC turned on, as standard users if at all possible

  • Give Microsoft feedback on how to improve UAC in the future using whichever feedback mechanisms are available to you. UAC is arguably the most important strategic security feature in Windows Vista. If we are ever to get away from the situation where everyone runs as an administrator all the time we must help make UAC work.

  • Complain to third-party vendors whose applications do not run properly under UAC. The only way those vendors will mend their evil ways is if people stop buying their products until they work properly. Check on http://www.threatcode.com before you spend money on software and nominate software you find that is broken and is not yet on the Web site.

  • Do not believe that UAC will protect you from malicious code. It is not designed to provide proper process isolation between processes on the same desktop.


Chapter 5: Managing Access Control

One of the most powerful and, at the same time, most complicated areas in security is that of Access Control Lists (ACL). ACLs are used to secure resources for both local and remote access. Per the official definition, ACLs enumerate which subjects have what type of access to which objects. Subjects in this sense are users and any program acting on their behalf. Objects are everything else that the subjects might want to access. Subjects are often referred to as "security principals" in Windows. A security principal is essentially equivalent to a subject, an entity that can be granted or denied access to something.

The net result of an ACL is that a user has a set of permissions to an object, such as a directory. These permissions can be the result of the user's direct permissions or group memberships. The effective permissions on a folder are show in Figure 5-1.

Image from book
Figure 5-1: The Effective Permissions tab evaluates permissions for any user.

This chapter is all about ACLs, and specifically how they have changed in Windows Vista and what that means for you, as the administrator of one or more Windows Vista systems. While a comprehensive coverage of ACLs is beyond the scope of this book, we will introduce you to enough of the basics to allow you to understand how access control is changing in Windows Vista. We start by reviewing a bit of terminology about ACLs to ensure that we have a common language for the discussion to follow.

Access Control Terminology

To understand how Windows Vista modifies how you work with ACLs you need to understand some of the basics about what ACLs are and how they work. In Chapter 4, we covered security identifiers (SID) and security tokens. In this chapter, we build on that with a review of the basic concepts related to ACLs. The reader who is comfortable with these concepts may wish to skip this section entirely. For a reader who is not familiar with ACL concepts at all, this section may not go into sufficient depth. However, if you feel you just need a review, this section should get you going and prime you for what is to come.

Securable Object

As mentioned in the chapter introduction, ACLs are applied to objects-more specifically, to securable objects. A securable object is, just as the name implies, an object that can be secured with an ACL. That covers pretty much any object you can think of as it turns out. Examples of securable objects, in Windows Vista, are:

  • Files

  • Directories

  • Registry keys

  • Services

  • The Event Logs

  • Network ports (new with Windows Vista)

  • Named pipes

  • A process

  • An event

  • Kernel objects

All objects that can be managed can also be secured, but unless you are a programmer, you will not be securing things like kernel objects, and you will probably not work with security in named pipes either. However, the other ones are very useful to work with. It is worth noting that with Windows Vista, and the new Advanced Firewall that comes with it, you can put an ACL on a port. We talk more about that in Chapter 11.

Access Control List

So far we have used the term "Access Control List" to describe a way to specify permissions on objects. This usage, although very common, is not technically correct, as it actually refers to how a Discretionary ACL (DACL) functions. As the name implies, a DACL is at the discretion of the system administrator and is used to control permissions. There are two other forms of ACLs: Mandatory ACLs (MACL) and System ACLs (SACL). Windows Vista supports SACLs and DACLs, but not MACLs. A SACL is identical in structure to a DACL, but specifies auditing to take place instead of permitted access. A MACL is managed and enforced by the system, and is not up to the system administrator to manage. It also specifies permitted access, but access based on object labels, as opposed to enumerated permissions. For example, if an object is labeled Top Secret, then if a user has Top Secret access, the user may access the object; if not, the access is denied. The system administrator cannot change this other than by re-classifying either the object or the user. MACLs are supported only in a few, specialized operating systems.

From now on, we will use the term DACL when we refer to an ACL specifying permissions, the term SACL to refer to an ACL specifying auditing, and the term ACL to refer to the general construct.

Security Descriptor

Every securable object has a security descriptor (SD). The SD is a structure that is associated with the object and is referenced whenever the object is accessed.

In the SD we specify who owns the object, which primary group that user is a part of, and the DACL and SACL applied to the object.

Access Control List Entry

When you look at an ACL you will see that it can specify several different types of access for the same user and access for several different users. Each of these entries is an ACL Entry (ACE). An ACL may contain many ACEs, up to about 65,000 theoretically. An ACE consists of the security identifier (SID) for the subject (see Chapter 4 for more information on SIDs), an access mask that specifies the access the subject has to the object, and a few flags that alter how the ACE is evaluated.

ACL Representations

There are several ways of representing an SD and its ACLs. Internally to the system they are a set of structures and pointers (C-language programming constructs that are familiar to every C/C++ programmer), containing fields using bitmasks to specify the contents of an ACL. When programmers and advanced system administrators work with SDs and ACLs they specify them in a language called Security Descriptor Definition Language (SDDL). SDDL is extremely powerful, and can get quite complicated. A thorough description of it is beyond the scope of this book. The interested reader is referred to the Platform Software Developers Kit (SDK), which can be downloaded for free from http://www.microsoft.com/downloads/results.aspx?pocId=&freetext=platform%20sdk&DisplayLang=en, and Chapter 17 of Protect Your Windows Network: From Perimeter to Data by Jesper M. Johansson and Steve Riley. Both discuss SDDL at length-the former with an emphasis on using SDDLs in software development, and the latter with an emphasis on using them in system administration.

Inheritance

Many objects, such as files, directories, and registry keys, allow propagation of ACEs from parents to children through inheritance. Inheritance can be extremely granular, and a single ACL may, and frequently does, have some ACEs that are inherited, and some that are not. ACEs can be inherited by children that are containers, such as directories; by children that are objects, such as files; or both. Container inheritance is specified with the flag CI in SDDL, while object inheritance is specified with OI. You may also see the flag IO, which means "Inherit Only." An ACE with the IO flag does not apply to the object it was specified on, only to its children. You will also see an I or ID flag, depending on which tool you are using. In either case it stands for "Inherited," meaning that the ACE was inherited from a parent.

Inheritance is an extremely powerful concept and can greatly reduce your administrative burden if you learn how to use it to your advantage. It can also completely destroy your system to the point where it is easier to flatten the whole thing and rebuild it than to fix it. This is especially true if you modify the default ACLs. The inheritance model will propagate changes deeply down the tree, and generally restoring the original ACL becomes impossible.

This is one of the major reasons why Microsoft has decided that it cannot support systems configured with third-party security guides. There are numerous instances where people applied inheritance incorrectly and ended up destroying their system. For instance, one site used an unsupported security configuration guide from a third party and propagated it with group policy without testing it first. The result was that the Administrator's profile was world readable and the recycle bin did not work. Both of those problems were somewhat mitigated, however, by the fact that users could no longer log on to the system. When they contacted Microsoft for a solution they were informed that the only guaranteed solution was to flatten and rebuild 10,000+ systems. They opted instead for a manual restore, which cost tens of thousands of dollars in consulting fees and weeks worth of lost productivity. Microsoft even published a knowledge base article highlighting the dangers of this and other unsupported security tweaks: http://www.support.microsoft.com/kb/885409.


How an Access Control List Is Used

When a user, or rather, a process acting on behalf of the user, opens an object the OS performs an access check before access is granted. The access check matches up the permissions on the object with the type of access the user requested. If the user has permissions granting the type of access requested, the access is granted. If even one is missing, the access is denied. In other words, say that you have a user foo, who has the following access to an object bar: read, write, execute. The user executes an application that attempts to open the object. The application asks for read, write, and delete access. In this case, the access attempt would be denied because user foo does not have delete access. It makes no difference if the application actually deletes the object or not. The mere fact that the application asked for delete access is enough to deny the entire request. If the application retries and asks for read and write access only, the access attempt is allowed.

At a more detailed level, the access check works following a very specific process. When the user attempts to access an object the OS determines what level of access was requested. Let us say the level of access was Read and

Write. The OS now retrieves the DACL on the object along with the process token for the process performing the access, and proceeds to evaluate whether the DACL grants the user the requisite permissions. The access check proceeds only until all requested permissions have been granted or a deny ACE is encountered that prohibits at least one of the requested access methods. If the user is a member of Administrators and the Administrators group is granted Read and Execute and the user is granted write access, then the access attempt would succeed. However, if the user is also a member of the Users group, and the Users group is denied write permission, then the access would be rejected because the application asked for write permission.

The DACL should follow a specific order. However, the operating system will not verify that the ACL is ordered correctly during an access attempt. That can cause some mildly surprising results. The recommended order specifies that explicit (non-inherited) deny ACEs go first, following by explicit allow ACEs. Then follows inherited deny ACES, in the order they were inherited. Finally, you have the inherited allow ACEs, again in the order they were inherited. The order within the inherited ACEs is based on where they were inherited from. The closer to the object you are trying to access the ACE came from, the higher in the order it goes.

This inheritance order can cause some unexpected results if you do not understand it and pay close attention to it when setting ACLs. Let us say, for example, that you have a directory and a file with the following permissions:

C:\>icacls c:\users\jesper\downloads\test /t
c:\users\jesper\downloads\test TEST\jesper:(OI)(IO)(DENY)(S,GR,GW)
                             TEST\jesper:(OI)(CI)(F)
                             NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                             BUILTIN\Administrators:(OI)(CI)(F)
c:\users\jesper\downloads\test\testDoc.txt TEST\jesper:(F)
                                         TEST\jesper:(I)(DENY)(R,W)
                                         TEST\jesper:(I)(F)
                                         NT AUTHORITY\SYSTEM:(I)(F)
                                         BUILTIN\Administrators:(I)(F)

In this case, you have a folder, called TEST. The SYSTEM user (also called LocalSystem) and all Administrators have full access to the folder. The user jesper has full access to the folder, but there is an inherit-only ACE that is inherited by objects, which denies jesper read (GR or Generic Read) and write (GW or Generic Write) access. Jesper also is denied Synchronize (S) access. Synchronize permits, or in this case, denies, jesper creating a synchronization handle to the object. Synchronization handles can be used, for example, to get notified when an object changes.

The deny ACE for Jesper is also inherited by the testDoc.txt file inside the test directory. You can see it there as the second ACE in the list and can tell that it is inherited (based on the I flag). However, it is not the first ACE in the list. The first ACE is the explicit full control ACE specified directly on the file. Now, what do you suppose happens when jesper tries to open the file? If you guessed "access is granted and the file opens normally" you are correct! This is counter-intuitive to many people who are used to hearing that deny ACEs take precedence over allow ACEs. They do, but explicit ACEs, whether inherited or denied, take precedence over inherited ACEs, whether inherited or denied. Therefore, the access is granted.

This result is very important because it means that putting deny ACEs on parent objects is not particularly meaningful as those ACEs may not be honored by children that have explicit ACEs on them. Ideally, you should grant permission only to those that should have it, and use deny ACEs extremely sparingly.

Another important thing to consider here is that while this ACL was ordered correctly, that may not always happen. Some third-party tools, and even builtin tools used incorrectly, may order the ACL incorrectly. In that case you may get some very strange results. If you use such tools, it is best to verify the ACL with the regular Windows ACL editor, also known as ACL UI. If the ACL is ordered incorrectly you will get an error stating this. You can also verify the ACL using icacls.exe command line tool with the /verify switch.

One very important thing to understand is the difference between an empty DACL and a NULL DACL.

  • An empty DACL is an ACL that has no ACEs in it. Remember that an ACE grants a subject permissions to an object. In other words, if a DACL is empty, nobody has been granted permissions.

  • A NULL DACL, on the other hand, is an object without a DACL. This is a very different thing from an empty DACL. An object that does not have a DACL at all has not been secured! This means the object is accessible to everyone. Many people have been told that the semantics of NULL DACLs were going to change in Windows Vista, and that they were going to be interpreted the same way as an empty DACL. This is not correct. Our testing shows that a NULL DACL is interpreted exactly the same way it always has been-as leaving the object without protection. In normal operations it is very rare to find a NULL DACL, at least on common objects. In order to create one a developer has to deliberately set one, which is usually done by misunderstanding how the APIs work. One of the more notable examples of a NULL DACL in the past several years was set on several data files by Microsoft's Age of Mythology game. In Windows XP, the ACL UI would present a NULL DACL as having Everyone Full Control, which is the effective equivalent. In Windows Vista ACL UI has been updated to actually show what really is going on, as shown in Figure 5-2.

Image from book
Figure 5-2: A NULL DACL means that the object has not been secured.


Major Access Control List Changes in Vista

The fundamental structure of ACLs in Windows Vista is relatively unchanged from Windows XP. Nevertheless, there are a large number of changes that you need to be aware of. ACLs in Windows XP played a large part in several problems:

  • Most Windows XP users run as an administrator using an account that is a member of the built-in administrators group. In fact, for home users, this is a virtual certainty because all the accounts added during setup become administrators. That means that any programs they execute will execute as an administrator. Consequently, those programs have unfettered access to the operating system without the user even realizing it. This is especially problematic if those programs are of the unsavory variety.

  • The default ACLs in earlier versions of Windows made many people nervous as they included ACL entries (ACE) for Everyone, Power Users, and the like. For instance, the default ACL on the C:\ in Windows XP gave Everyone read access and granted permission to create folders for Users. In Windows Vista, it has changed slightly.

  • There was no way to assign permissions to the current owner of an object. You could give the creator owner permissions but if the owner changed those permissions were not transferred to the new owner.

  • Owners always have implicit rights to an object, no matter what permissions they are assigned on that object.

In Windows Vista, Microsoft embarked on a project to resolve these issues. In the remainder of this chapter, we look at the major changes related to access control that came out of that project, and then finish by looking at the tools you use to manage access control in Vista that are new or modified from Windows XP. It is assumed throughout that you are already familiar with how to manage access controls in Windows XP.

Image from book
WINDOWS XP DEFAULT ACLS

Windows XP had a reasonably sane ACL on it. However, some original equipment manufacturers (OEM) apparently decided they knew far better than Microsoft what made reasonable security. Consequently, Hewlett-Packard, for instance, shipped thousands of Windows XP Media Center Edition systems with a DACL that had Everyone:Full Control through the entire system drive. Dell has also shipped systems with a non-standard ACL, but in that case it was far more restrictive than the default ACL. In this section, however, we will not be comparing Windows Vista to such follies, but rather restrict ourselves to a comparison between the defaults that Microsoft gave Windows XP and Windows Vista.

Image from book

Least Privilege

The first of the problems listed was that of running as an administrator far too often. The problem is almost exclusively rooted in access control in that the reason people needed to run as an administrator was that none of their programs worked otherwise. However, the solution was User Account Control (UAC), which was discussed in Chapter 4. Therefore we will not go into that further here.

New and Modified Users and Groups

There are some changes to built-in users in Windows Vista. Some of them are new; some are modifications to how existing users and groups work, and a few have been removed. Each of them has some impact on how you manage access control, so it is important that you are familiar with the changes.

Administrator-Disabled By Default

As mentioned in Chapter 4 the biggest change here is that the Built-in Administrator account, the one with a relative identifier (RID) of 500, is now disabled by default in most cases. Eventually, Microsoft may deprecate that account altogether, but for now, it is disabled by default. If you have no other local accounts in the Administrators group then RID 500 is still usable in the recovery console and safe mode, but otherwise it cannot, and should not, be used. Using that account violates the important security principle of accountability as you lose ability to track who is making changes on your system.

Image from book
THE ADMINISTRATOR VERSUS ANY ADMINISTRATOR

There is at least a semantic difference between the built-in Administrator account and any other account in the Administrators group. To distinguish custom accounts from the built-in accounts we will capitalize "Administrator" when referring to the account with RID 500 (Administrator on English builds of Windows) to distinguish it from an "administrator," which is any other account that is a member of the built-in Administrators group.

In Windows XP, the built-in Administrator account also had a number of special rights and privileges that any other administrator did not. Almost all of these special-case treatments of Administrator have been removed in Windows Vista. One of the few remaining is that a disabled Administrator account can be used in the recovery console if there are no other local administrators.

Image from book

Power Users Permissions Removed

The old Power Users group has, for all practical purposes, been removed, as we discussed in Chapter 4. The group is still there, but almost all the permissions granted to it have been removed. It was not exactly a secret that a user that was a member of Power Users was effectively an administrator that had not made themselves an administrator yet. On a fully patched computer running Windows XP Service Pack 2, one of the authors, starting from scratch, granted himself administrative privileges in less than 45 minutes, and that included the reconnaissance, writing a small program in C++, and logging off and on again to complete the take-over-all because his user account was a member of Power Users.

Microsoft is planning on completely removing Power Users in an upcoming version of Windows. However, many organizations have granted sophisticated permissions to that group and rely on their users being members of it. Therefore, it was not feasible to remove the Power Users group in Windows Vista. You would be well advised to start planning a migration off Power Users, though, if you are still using them.

Trusted Installer

The Trusted Installer is, strictly speaking, not a user at all. It is actually a service. In Chapter 6 we discuss service hardening, which allows each service to be considered as a full-fledged security principal that can be assigned permissions just like any other user. In Chapters 6 and 11 we will see how this new feature is highly leveraged in Windows Vista. The full name for this virtual account is NT SERVICE\TrustedInstaller and its SID is:

     S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

Contrary to the SID you saw earlier for the Administrator account, this one begins with S-1-5-80. Notice that the first sub-authority here is 80, which stands for SECURITY_SERVICE_ID_BASE_RID, meaning this one SID is issued to a service. The display name for the TrustedInstaller service is called "Windows Modules Installer."

Help and Support Accounts Removed

The Support_xxxxxx and HelpAssistant accounts are both removed on clean installs. The Support_xxxxxx account was used to run scripts from the support center. Some OEMs that provided their own help content may also have provided their own support accounts. It is unclear as of yet what will happen to such accounts, but they are strictly speaking not necessary any longer. In fact, from a security perspective, it was not a great idea to allow users to execute scripts from the help center as another user anyway, so it would be best if those accounts disappear. Windows Vista has a new mechanism to accomplish this task if needed.

The HelpAssistant account was used during remote assistance. As with the help center, the remote assistance feature has been re-engineered to avoid the need for the HelpAssistant account, and consequently it has been removed.

New Network Location SIDs

Windows NT-based operating systems have always had some network location-based SIDs, such as NETWORK and INTERACTIVE, denoting users that are logging on from the network and interactively, respectively. There is also a REMOTE INTERACTIVE LOGON SID, which is assigned to users logging on via Terminal Services. Note that Terminal Services users actually will have both REMOTE INTERACTIVE LOGON and INTERACTIVE LOGON in their tokens. In Windows Vista, two more are added: DIALUP and INTERNET. The exact rationale for adding an account denoting a logon via Dialup-particularly to a client operating system that should not act as a remote access server in an age where more and more users are taking the perfectly sensible stance that if the only network available is a phone line, they are not online-is a bit unclear, but it is there now. INTERNET is obviously meant to denote any user that logged on from beyond the local area network. NETWORK, however, still denotes any user logging on from the network, including the Internet.

OWNER_RIGHT and Owner Rights

There is now a SID for OWNER RIGHTS. This SID applies to whoever happens to own the file at the time it is accessed. It is primarily used to restrict what the owner can do with the file. There are two primary changes to how owner rights work as compared with Windows XP. First, if you are the owner of the object, but there is an ACE on the object that applies to you, the rights in the ACE will supersede the fact that you are the owner. In other words, the owner no longer has implicit full control to the object. Second, the OWNER_RIGHT SID can be used to further restrict what the owner can do with an object. An example will help illuminate this.

Let us assume we have a folder with the following ACL:

C:\Windows\system32>icacls c:\users\jesper\downloads\test
c:\users\jesper\downloads\test NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                             Jesper-Vista\Jesper:(OI)(CI)(RX)

The user Jesper has only read permission on the folder, but Jesper is the owner. Yet, if he tries to copy a file into it, the copy will fail because Jesper does not have permission to write to the folder. This is not entirely intuitive from the error messages received, however. If you attempt to copy a file into this folder using Windows Explorer, here is what happens.

  1. Explorer tells you that you need to elevate to copy the file.

  2. Explorer asks you to elevate.

  3. The file copy fails because you do not have rights to copy anything into this folder. This is in spite of the fact that you are the owner.

If Jesper tries to change the ACL on the file, he will get prompted to elevate his token to do so. Because he is the owner of the file, he can still do so. The owner has implicit right to read and change the ACL (READ_CONTROL and WRITE_DAC) unless there is an ACE for OWNER RIGHTS that specifies otherwise.

To understand the effect of the OWNER RIGHTS SID let us add that to the previous ACL:

C:\Windows\system32>icacls c:\users\jesper\downloads\test
c:\users\jesper\downloads\test NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                             Jesper-Vista\Jesper:(OI)(CI)(RX)
                             OWNER RIGHTS:(OI)(CI)(M)

In this case, if Jesper-Vista\Jesper tries to copy something into the folder, it succeeds immediately because Jesper is the owner, and has the rights to do this. However, if Jesper tries to change the ACL on the object, it will fail! The ACE for OWNER RIGHTS specifies that the owner shall have only modify privilege, not the ability to modify the DACL. Thus, OWNER RIGHTS is used primarily to remove WRITE_DAC, the ability to modify the security descriptor, from the owner.

If an administrator changes the owner of the object the OWNER RIGHTS permissions are not automatically transferred to the new owner. In this case the OWNER RIGHTS ACE is disabled by marking it as inherit-only but not applying to either containers or objects, in other words, not applying to anything at all. That is done to ensure that administrators do not get completely locked out of the object. To get the OWNER RIGHTS ACE to take effect again, the Administrator has to go in and manually re-enable the ACE. Therefore, to re-enable it, you would mark it as applying to this folder, subfolders, and files, as desired.

There are several interesting scenarios where the OWNER RIGHTS SID can be useful. For example, consider the following:

  • The administrator wants users to be able to create files and folders on a file server, but does not want users to be able to change ACLs on those folders.

  • Users were members of a group at some point and created some objects. However, for business reasons, they were removed from this group after a period of time. At this point, they should not be able to modify the settings on those objects.

  • OWNER RIGHTS is used fairly extensively in Service Hardening (see Chapter 6). When a service creates a transient object at runtime, the creator of the object is the primary SID of the service process, typically LocalSystem, NetworkService, or LocalService, and not the SID for the service itself. That means that any other service running in the same process context can modify the object, which is almost certainly not desirable. By setting an OWNER RIGHTS SID on the objects, the OS can keep other services from accessing them.

Default ACLs

There are several significant changes to the default ACLs in Windows Vista. First, if you are used to using Windows XP you are used to all OS files being owned by the Administrators group, and to administrators having full control over those files. That means that as a member of that group you had unfettered access to those files. This is not the case in Windows Vista.

Trusted Installer

In Windows Vista, most of the OS files are owned by the TrustedInstaller SID, and only that SID has full control over them. This is specifically to prevent a process that is running as an administrator or Local System from automatically replacing the files. This is really part of the system integrity work that went into Vista. It means that in order to delete an operating system file you need to first take ownership of the file, and then add an ACE on it that lets you delete it. It is a thin layer of protection against a process that is running as LocalSystem and has a System integrity label, but a process that has lower integrity is not supposed to be able to elevate to change ownership. Some services, for instance, can run with medium integrity, even though they are running as Local System. Those services cannot replace system files. That means that an exploit that takes over one of those services cannot replace operating system files, making it a bit harder to install a rootkit or other malware on the system.

Deny ACEs

You will find that many objects in the file system have deny ACEs for Everyone. This has caused quite a bit of consternation to many people. If you turn on the Show hidden files option, you will see the familiar Documents and Settings directory that you have known since Windows 2000. However, if you click it, you will get an Access Denied error. Few people understood what happened, and we have seen many complain about a "tyrannical operating system" that is locking them out of their files.

To understand what is going on with Documents and Settings, look at this directory listing:

C:\>dir /a
  Volume in drive C has no label.
  Volume Serial Number is 647C-D56F
  Directory of C:\
<snip>
10/04/2006  01:15    <JUNCTION>     Documents and Settings [C:\Users]
<snip>

Documents and Settings is, in fact, not a directory at all! It is a junction point. Recall that junction points are similar to symbolic links that just redirect the access to somewhere else. In this case, the junction goes to a directory called C:\Users. Microsoft has actually modified the name space of the file system significantly in Windows Vista, and the user data is now moved to C:\Users. Other things underneath the old C:\Documents and Settings\< Username > name space have also moved. For example, "C:\Documents and Settings\ < Username >\Application Data" has moved to C:\Users\< username >\ appdata\roaming. You can see the changes very clearly if you drop to a command line and use the dir /a command. The name space has changed so drastically primarily to make it more intuitive to users, and to get a clearer separation between documents and data. Rather than storing all data files under My Documents, developers can now create their own folders under the user's profile. Theoretically, the user will see them there and find this intuitive.

Microsoft did not remove the "C:\Documents and Settings" name space because older applications may be hard coded to use that name rather than the preferred environment variables, such as %USERPROFILE%. Those applications would break if C:\Documents and Settings were to disappear all of a sudden, so the junction points are there for backward compatibility. These applications already break on Windows versions in languages other than English. In other words, those programs are already broken! This is really key. Quite frequently when an update to Windows, such as Windows XP SP2 or Windows Vista, breaks third-party programs it is because developers of those programs made invalid assumptions or used Windows in a way they were not supposed to.

If you try to open a file, for example by typing C:\Documents and Settings\< yourUsername >\My Documents\foo.txt, that would work, assuming you have a file called foo.txt in there. However, if you try to browse to C:\Documents and Settings\< your username >\My Documents you get the Access Denied error message. To understand what is happening, look at this ACL:

C:\>icacls "Documents and Settings"
Documents and Settings Everyone:(DENY)(S,RD)
                      Everyone:(RX)
                      NT AUTHORITY\SYSTEM:(F)
                      BUILTIN\Administrators:(F)

Look at the first ACE in the list. It is a deny ACE for Everyone to List the Folder contents. Programs can traverse the junction points and open documents with absolute paths, but if they try to enumerate the directories they represent they will fail because of the deny ACE. That is why you cannot actually see what is inside C:\Documents and Settings, nor can you delete the "directory." This is the main point of putting that deny ACE on it. It is there primarily to prevent users from deleting the junction and break older applications. It also will serve to remind developers not to code applications to use the old name space, but start using environment variables instead to insulate themselves from any future changes.

We should also mention that all these junction points are hidden by default, so the vast majority of users will never see them. To prevent those that do from deleting it Microsoft put that deny ACE in for List Folder.

Image from book
BYPASS TRAVERSE CHECKING

You can open files within directories that you do not have access to because of a privilege called Bypass Traverse Checking, or SeChangeNotifyPrivilege, internally. SeChangeNotifyPrivilege is actually the most basic privilege in Windows and is granted even to a process that has all other privileges removed unless the process specifically requests to have that privilege removed, too. This is what happens when you launch a process using the runas/trustlevel:0x10000 < command > command line in Windows Vista. The program specified in < command > will run with a restricted token and all privileges except SeChangeNotifyPrivilege stripped from the process token.

As a point of interest, trustlevel 0x20000 gives you a token with the normal set of SIDs but with almost completely stripped privileges. 0x40000 gives you a completely normal token.

Image from book

Default Permissions

The default permissions on the file system in Windows Vista have changed a little from Windows XP. If you look at the ACL on %systemdrive%, normally the C: drive (the boot partition), on Windows XP or Server 2003, you see this:

     D:AR
     (A;OICI;FA;;;BA)
     (A;OICIIO;FA;;;CO)
     (A;;0x1200a9;;;WD)
     (A;OICI;FA;;;SY)
     (A;OICI;0x1200a9;;;BU)
     (A;CI;0x100004;;;BU)
     (A;CIIO;0x100002;;;BU)

Here is the same ACL on Windows Vista:

     D:PAI
     (A;;FA;;;BA)
     (A;OICIIO;GA;;;BA)
     (A;;FA;;;SY)
     (A;OICIIO;GA;;;SY)
     (A;OICI;0x1200a9;;;BU)
     (A;OICIIO;SDGXGWGR;;;AU)
     (A;;LC;;;AU)

There are several differences here worth noticing. First, there are now two ACEs for BA (BUILTIN\Administrators) instead of just one. However, the net effect is the same. The same holds true in the replacement of the one ACE for SY (LocalSystem) with two in Windows Vista. In Windows XP, the single ACE granted full access and was inherited by objects and containers. In Windows Vista, one ACE is not inherited and grants full access to the root, and one ACE is an IO (Inherit-Only) ACE, inherited by containers and objects, and grants GA (Generic All, or full control). Again, there is no net change here. The main reason why the ACL was changed was to clarify and break out the privileges so that the ACL is easier to manage, and potentially even possible to restore.

More interestingly, the ACE for CO (Creator/Owner) is gone. That means that there are no special permissions for the person that creates an object. If a user creates an object in the root of the file system, no special permissions are accrued to the creator any longer.

We also notice that the ACE for WD (Everyone) has been removed. Many people who were interested in security, although they may not have completely understood the implications of their actions, were unduly concerned about that ACE. Microsoft tried in vain for years to explain that Everyone was functionally identical to Built-In Users, but it appears they finally gave up and removed that ACE altogether. Because there is an identical ACE for BU (BUILTIN\Users) that is also inherited by both containers and objects, the net effect is that nothing has changed.

In addition, two of the ACEs for BU (Built-in Users) have been replaced with ACEs for AU (Authenticated Users). The reason for this is that the Guest account is a member of Built-in Users, (by virtue of the fact that INTERACTIVE is a member of Built-In Users), but not of Authenticated Users. To allow the Guest account to read and execute files, the 0x1200a9 (effectively Read and Execute) ACE remains granted to BU. However, the ACEs that grant permissions to create files and folders are granted to Authenticated Users instead. This is a departure from Windows XP. In Windows XP, a regular user and even a Guest could create files in the root. In Windows Vista, they cannot.

There are a couple of very interesting, and on the surface, troublesome, ACEs in the two default ACLs. In Windows XP, you see an ACE inherited by containers, specifying 0x100004 for Built-In Users. That ACE grants Users the right to create subdirectories, and sub-subdirectories because it is inherited by containers. We also see an inherit-only ACE, inherited by subfolders for 0x100002. That ACE grants users the right to create files and subdirectories in folders they create under the root. In other words, these two ACEs allow users, including Guests, to create files and folders under the root, as we mentioned before.

In Windows Vista, the corresponding ACEs are an inherit-only ACE, inherited by both containers and files, granting GR (Generic Read), GX (Generic Execute), and GW (Generic Write) along with SD (Read Security Descriptor); and an ACE that applies only to the root itself that grants LC privilege. LC is actually a shortcut hat belongs on ACEs in Active Directory. In Active Directory it means that a user can list child objects. However, the hexadecimal value of LC is 0x4. For a directory, 0x4 means FILE_ADD_SUBDIRECTORY, which becomes functionally equivalent to 0x100004 because you already have 0x100000 (the ability to use the object for synchronization) from the 0x1200a9 ACE. In other words, it gives you exactly the same effect as you have in Windows XP-users can create subdirectories under the root. The permissions granted to those subdirectories in Windows Vista are governed solely by the SDGXGWGR ACE for Authenticated Users. This is the biggest difference between Windows Vista and Windows XP. Rather than granting full control to the creator of subdirectories, as was done in Windows XP, Windows Vista grants modify privilege to authenticated users.

The net result of this new ACL is that the creator of an object no longer has any special rights, and that things are a little clearer, and a little simpler. Authenticated Users have Modify privileges even on subfolders that are created by administrators, which is very different from Windows XP. In Windows XP, Users and Authenticated Users have no rights to objects created by administrators under the root. Other than that, while these ACEs may look troublesome, the net effect is not that different from in Windows XP.

Image from book
NOTE ON ICACLS

It is interesting to note, that the icacls tool, which was used to generate the output in the preceding listing, reduces ACEs to shortcut codes that are designed for a different object type. This turns out to not be uncommon and is basically done on a matching basis with whichever shortcut comes first in a list. The same happens with the sc.exe command and with the Security Configuration Editor.

Another interesting issue with icacls is how it interprets drive names. If you run this command:

     c:\windows\system32>icacls c:\

you get the ACL on C:\. However, if you run this command:

     c:\windows\system32>icacls c:

You will get the ACL on C:\windows\system32 instead. Icacls does not fully understand drive letters so it considers C: to be an unknown path. Rather than throwing an error when it sees that, it gives you the ACL for the current directory.

Image from book

To summarize, in Windows Vista, everyone, including the Guest user, can read and execute files in the root. Only authenticated users can create new files and folders, and when users do, they get modify permissions on those files and folders. In other words, the permissions are marginally tighter on Windows Vista than on Windows XP, although it is worth noting that the Guest account is disabled by default.

Share Security

The default share permissions have been changed from Windows XP. In Windows XP, the default ACL on shares was Everyone:Full Control. In Windows Server 2003, and now also in Windows Vista, the default share permissions are Everyone:Read.

Using Everyone:Read as the default share permissions actually cost a fair bit in support costs until administrators got used to it. The default ACL was changed in response to outcries from a number of people that Everyone:Full Control was always a bad ACL. Clearly, the people making such cries fail to understand what Everyone:Full Control means on a share. When a subject accesses a file on a share, the operating system grants access only if both the permissions on the share and the permissions on the file system underlying the share grant the requested access. If either does not grant all required accesses, the attempt fails. This means that setting Everyone:Full Control on a share does not grant the user any access whatsoever. It merely means "I do not want to control access here." In essence, it is a way to simplify access control management by managing ACLs only on the file system, and not on the share.

Unfortunately, Microsoft listened to the people who ignored this basic fact and changed the default permissions on a share, requiring administrators to, in most cases, modify share permissions as well as file system permissions to create useful shares.

On a more positive note, Microsoft added some additional controls in the Share tab of the properties dialog box on a file, shown in Figure 5-3.

Image from book
Figure 5-3: The Sharing tab received a makeover in Windows Vista.

The new Sharing tab puts more of the controls for shares at the user's disposal. First, there are additional options hidden under the Advanced Sharing button that were not there before. Second, the user now receives a message that explains how access is managed for this computer, whether with user-name and password or if all users connect anonymously.

Changes to Token

As we discussed in Chapter 4, a very important change is made to the user's security token in Windows Vista. When a user that is a member of the Administrators group in Windows XP logs on, their token contains the Administrators group SID, and they can do anything that the Administrators group can do. In Windows Vista, on the other hand, because of User Account Control this is no longer the case. As we mentioned, the Administrators SID is still present in the token, but is set to deny only. When performing access control such an ACE is used only to deny access. Any allow ACEs for that SID are ignored. That means that you really are not truly an administrator all the time, even if you log on to the system as one.

Integrity Levels

As we mentioned in Chapter 3, Windows now supports labeling of processes and objects with integrity levels. These integrity levels are actually represented as ACEs as well, but not in the DACL. They are instead a part of the SACL, with a few special flags. For example, the flag NW is used to denote a blocking of a process at a lower integrity level from writing to an object at a higher integrity level (SDDL_NO_WRITE_UP).


Tools to Manage Access Control Lists

In addition to the updates to ACLs mentioned previously, Microsoft has also updated some of the tools you use to manage ACLs. Interestingly, the most significant of these updates are command-line tools.

Cacls and Icacls

Most people are familiar with the venerable cacls tool that has been in every version of Windows NT since it first came out. If you run cacls.exe in Windows Vista you are greeted with this message:

     Microsoft Windows [Version 6.0.5744]
     Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

     C:\Windows\system32>cacls

       NOTE: Cacls is now deprecated, please use Icacls.

A new tool, called icacls, will eventually completely replace cacls. Cacls, as you may be aware, was never completely updated to support the more granular permissions introduced with Windows 2000, making this an update that is about seven years overdue.

In spite of it being deprecated, cacls does actually include some new features. First, it is aware of both junction points and symbolic links, and knows to traverse those now. Second, it can both print and set an ACL using an SDDL string, which it was never capable of doing.

In spite of the updates to cacls, it is icacls you want. Icacls has some very useful functionality that you are sure to appreciate

Save ACLs

A constant wish for the past 10 years has been the ability to save an ACL so that you can restore it at a later date. This turns out to be one of the most complicated operations you can perform on ACLs. Except in certain special cases, it is unlikely that you get back to exactly where you would have been had you not ruined the ACLs in the first place. For some elaboration on the difficulties of saving and restoring ACLs, see the sidebar "Saving/Restoring ACLs." Nevertheless, it can be quite useful.

To save an ACL you run icacls with the /save switch:

     icacls <directory or object> /save c:\acls.bin /t

This would save the ACLs to a file called acls.bin. The file will contain one line for each object with an ACL followed by one line specifying the ACL in SDDL. If you use the /t switch, the command will operate on the object you specified and all objects and containers underneath it.

The save functionality is a welcome addition to the toolkit, but it is lacking in several respects. First, it saves only the DACL, not the SACL. In fact, if there is a SACL, it saves a dummy value that indicates this, but it does not actually save any part of the SACL.

Image from book
SAVING/RESTORING ACLS

Say you have a hierarchy containing user data for students at a local college. You save the ACL on February 1. On April 17 you discover that somehow the ACL has been corrupted and you go to restore it from the saved copy. What complications could there be with this operation? First, the new quarter started on April 2. About 15 percent of your students graduated and are no longer with you; consequently, their directories no longer exist. Thus, you have ACLs in the backup file that are invalid. You also have a batch of new students, another 15 percent that started with the new quarter. They have home directories now, but no ACLs in the backup file. What should their ACLs be? Then, of course, you have the 70 percent that are still there, but they have created new files and folders, and deleted others. You can ignore the deleted ones, but how do you configure the new folders they created? What if a student decided to share a folder with his friends on March 4? Will you break that? Clearly, saving and restoring ACLs is not nearly as simple an operation as many people would have you believe.

Image from book

Restore ACLs

Once you have saved an ACL using the /save switch you can restore it using the /restore switch. Before you go any further, however, you probably want to read the sidebar with the warning about editing saved ACLs.

Image from book
WARNING: DO NOT EDIT YOUR SAVED ACL

If you were to open the file containing your saved ACL in a text editor you would find that it appears to be a Unicode formatted text file. In fact, that is almost exactly what it is. This might lead people to edit it, or save it from the text editor. If you open the file with the saved ACLs in a text editor and save it you will not be able to restore the ACLs from it. It is not actually a Unicode formatted text file after all. Such a file must begin with the two bytes 0xfffe. If you save the file with a text editor, such as Notepad, it will in fact put that flag into the file in the first two bytes. The icacls tool will then be unable to parse the ACLs in the file as it expects the first two bytes to be part of the string specifying the object to operate on. Your backup file will be unusable.

Microsoft is aware of this problem, but as it was only reported very late in the beta cycle for Windows Vista, it was not fixed prior to release. At this point we do not know when, or even whether, it will be fixed so for now, the best advice is to not edit your saved ACLs.

Image from book

The restore command in its simplest form looks like follows:

icacls <directory> /restore acls.bin

The restore command does not operate on files. For instance, look at this sequence of commands:

C:\Users\Jesper\Downloads>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper\Downloads>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files
C:\Users\Jesper\Downloads>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

Here we create a save file by pointing icacls at a file. We then try to restore it by simply substituting /restore for /save. This fails for the reason just mentioned-the restore command operates on directories only. The files it is supposed to modify are specified in the acls.bin file already. To restore the ACL we point it at the directory instead of the file. This we do in the last command where we specify "." as the object to operate on-"." obviously being the current working directory.

Substitute SIDs

Another very useful feature in icacls is the ability to replace the permissions for one user with permissions for a different user. This is done during restore using the /substitute switch. The documentation for the substitute switch says it needs an SID, but further down it explains that this can actually also be a regular user name. Thus, the following sequence works:

     C:\Users\Jesper\Downloads>icacls test.txt
     test.txt VistaRC2-Test\foo:(R,W)
              VistaRC2-Test\Jesper:(I)(F)
              NT AUTHORITY\SYSTEM:(I)(F)
              BUILTIN\Administrators:(I)(F)
     Successfully processed 1 files; Failed processing 0 files
     C:\Users\Jesper\Downloads>icacls test.txt /save acls.bin
     processed file: test.txt
     Successfully processed 1 files; Failed processing 0 files

     C:\Users\Jesper\Downloads>icacls. /substitute foo bar /restore acls.bin
     processed file: .\test.txt
     Successfully processed 1 files; Failed processing 0 files
     C:\Users\Jesper\Downloads>icacls test.txt
     test.txt VistaRC2-Test\bar:(R,W)
              VistaRC2-Test\Jesper:(I)(F)
              NT AUTHORITY\SYSTEM:(I)(F)
              BUILTIN\Administrators:(I)(F)
     Successfully processed 1 files; Failed processing 0 files

As you can see, we have the exact same ACL as we did before, but the ACE that used to specify permissions for foo now specifies them for bar instead.

Change Owner

The chown tool has been a staple in Unix for years. Windows originally had no built-in way to change the owner of an object. Then came the setowner tool in the resource kit. Then came the takeown tool in the OS, but it only allowed you to take ownership, not grant it to others unless you had their password. Finally, you have icacls with the ability to set the owner of objects you have permission to set the owner on:

     C:\>icacls c:\test /setowner foo
     processed file: c:\test
     Successfully processed 1 files; Failed processing 0 files

Unfortunately, icacls can neither show you the owner of an object, nor provide you with any further indication that your request to change the owner works than the "Successfully processed …" message. This seems to be a grave oversight. There is no way to actually see, from the command line, who the owner of an object is. Furthermore, if you save the ACL for an object, it does not save the owner of the object.

There is also a bug in icacls in that it does not invoke the SeTakeOwnership-Privilege to change the owner. If you have the right to change the owner of an object based on the ACL, icacls works as it should. However, if you are an administrator, but you do not have permission to change the owner based on the object's ACL, you cannot use icacls to do so. In that case you need to use the takeown.exe tool, which does invoke the SeTakeOwnershipPrivilege, but can change the owner only to your account or the Administrators group, not to an arbitrary account:

     C:\>takeown /f c:\test
     SUCCESS: The file (or folder): "c:\test" now owned by user "JJ-
     VistaRTMTst\Jesper".

Find All Aces Granted to a Particular User

Icacls has another very useful function: It can find files that have permissions for particular users. For example:

     C:\windows\system32>icacls "c:\program files" /findsid jesper /t
     SID Found: c:\program files\Passgen\passgen.exe.
     Successfully processed 1808 files; Failed processing 0 files

This could be very useful if you are trying to find out what a particular user might have access to.

Resetting ACLs

If an ACL has become corrupted, or destroyed, icacls has a way to reset it to inherit from its parent. This is actually something that would have been extremely useful in the fall of 2006. One way to mitigate a recent zero-day security issue in a Windows component was to deny Everyone access to the object. That part was easy, but removing that ACE was impossible using builtin tools in Windows XP and Server 2003. In Windows Vista, you would have merely run this command:

     C:\windows\system32>icacls "c:\program files\directory\file.exe" /reset
     processed file: c:\program files\directory\file.exe
     Successfully processed 1 files; Failed processing 0 files

Grant/Deny/Remove

Icacls, of course, has all the standard grant/deny/remove operations. The only really new item in that list is the remove operation. Using that switch, you can remove all allow ACEs, all deny ACEs, or both for a given user from a specific object or hierarchy. For example:

     ilC:\>icacls c:\test /grant foo:(F)
     processed file: c:\test
     Successfully processed 1 files; Failed processing 0 files

     C:\>icacls c:\test
     c:\test JJ-VistaRTMTst\foo:(F)
             BUILTIN\Administrators:(I)(F)
             BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

     Successfully processed 1 files; Failed processing 0 files

     C:\>icacls c:\test /remove:g foo
     processed file: c:\test

     Successfully processed 1 files; Failed processing 0 files

     C:\>icacls c:\test
     c:\test BUILTIN\Administrators:(I)(F)
             BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

     Successfully processed 1 files; Failed processing 0 files

     C:\>icacls c:\test /deny foo:(F)
     processed file: c:\test
     Successfully processed 1 files; Failed processing 0 files

     C:\>icacls c:\test
     c:\test JJ-VistaRTMTst\foo:(N)
             BUILTIN\Administrators:(I)(F)
             BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

     Successfully processed 1 files; Failed processing 0 files

     C:\>icacls c:\test /remove:d foo
     processed file: c:\test
     Successfully processed 1 files; Failed processing 0 files

     C:\>icacls c:\test
     c:\test BUILTIN\Administrators:(I)(F)
             BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

     Successfully processed 1 files; Failed processing 0 files

The ability to remove only the deny ACEs can be very useful if you want to open access to an object up to a particular group or user.

Set Integrity Level

Icacls also has the ability to display and set integrity levels. As we discussed in Chapter 3 and earlier in this chapter, Windows Vista supports integrity labels on objects. That means there must be a command-line tool to do so, and icacls is it.

     C:\>icacls c:\test /setintegritylevel high
     processed file: c:\test
     Successfully processed 1 files; Failed processing 0 files

     C:\>icacls c:\test
     c:\test BUILTIN\Administrators:(I)(F)
             BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
             Mandatory Label\High Mandatory Level:(NW)

     Successfully processed 1 files; Failed processing 0 files

Note that icacls displays an integrity label only if an object has one explicitly set. Most files do not, so it is rare that you see one.

ACL UI

ACL UI, or the ACL User Interface, is a term that describes the graphical user interface (GUI) used to manage ACLs. It has been modified slightly from the one in Windows XP. In Figure 5-4 you see the ACL UI dialog box from Windows XP.

Image from book
Figure 5-4: ACL UI dialog box in Windows XP

Compare the ACL UI dialog box in Figure 5-4 with the same dialog box from Windows Vista, shown in Figure 5-5.

Image from book
Figure 5-5: ACL UI dialog box from Windows Vista

As you can see, there are a few changes here. First, the dialog box finally shows the object you are operating on very clearly, which can be useful if you are working on several objects at a time. Second, there is a hyperlink to offer some help at the bottom. However, the most notable change is in the removal of the Add and Remove buttons, which are replaced with an Edit button. The Edit button is largely present in support of UAC (see Chapter 4). As you can see by the shield on the button, the user that launched this dialog box is not running with an administrative token, and therefore will require elevation before she can edit the permissions. If the user has permission to modify the ACL, the shield would not be present. That shield signifies a COM Moniker, which we discussed in Chapter 4. If you click the Edit button, you get the familiar elevation dialog box, and if you click yes, you get a dialog box that is almost identical to the one you get in Windows XP by default. In several places ACL UI follows this "dual dialog" concept. You get one dialog box until you elevate, and once you do, you get the dialog box you are used to from earlier versions of Windows.

If you click the advanced button and then the Auditing tab you will always get an elevation button, as shown in Figure 5-6.

Image from book
Figure 5-6: Modifying the audit settings in Windows Vista always requires elevation.

You cannot modify auditing without elevating, even if you have full control over the object and you are the owner. The ability to modify an object SACL is governed by the SE_SECURITY_NAME privilege, known as "Manage auditing and security log" in the GUI tools. Only administrators have that right by default, however, the privilege is removed from an admin in admin approval mode, necessitating the elevation if you are an administrator.

One final note on the elevation needs when you modify ACLs: All these statements are contingent on your not disabling UAC. If you disable UAC, all behavior reverts to the one you had in Windows XP, with the exception that the dialog boxes will look different. However, no elevation will be required, provided you log on as an administrator because your token will now have the Administrators SID in it all the time.

Other Tools

While icacls is a very useful tool, and a grand improvement over cacls, it still suffers from some shortcomings. Perhaps the most notable is that it cannot manage access to any other objects than files and directories. Windows Vista makes very sparse changes to the ACLs to other objects, compared to Windows XP, but there are still occasions when you want to manage ACLs on a service, a registry key, or even an Active Directory object.

If you are a command-line junkie, you need subinacl to do this. Subinacl is in the support tools, and is also available as a free download. Go to http://www.download.microsoft.com and search for subinacl to find the most recent version. We have to warn you, however, that subinacl is not easy to use. In fact, it is downright obtuse at times. However, there is no more powerful tool to manage access control available. If you are a power admin, you really need that one.


Registry ACLs

The registry ACLs have undergone changes, just like the file system ACLs. The changes are much smaller in scope than the changes to the file system, however. The most obvious difference from earlier versions of Windows is that, because of the deprecation of Power Users, almost all the Power User ACEs are gone. Power Users are not supposed to be any more powerful than any other users in Windows Vista. It is a testament to just how complicated ACLs really are, however, that not all the ACEs for Power Users are actually gone. A few were, unfortunately, missed.

While you are looking at ACLs in the registry, in a few places you will see an ACE for a SID called RESTRICTED. This is not new to Windows Vista, but it is an interesting and not well understood SID. That SID denotes any process that presents a restricted token. A restricted token is created using a special feature of the CreateRestrictedToken API. Such a token has one or more "restricting SIDs"-SIDs that are used in a separate access check. When a process running with a restricted token attempts to access an object with an ACE for the RESTRICTED SID, the OS actually performs two access checks. The first is the normal access check. The second one works exactly like the first but takes place only against the restricting SIDs in the token. Both access checks must pass.

Currently, several ACLs use the RESTRICTED SID, particularly in the Registry. A screenshot of such an ACL is shown in Figure 5-7.

Image from book
Figure 5-7: The Registry ACLs include an ACE for RESTRICTED in several places.

At this time, few processes make use of the restricted token functionality, particularly with respect to restricting SIDs. One example of a process that does is the service process that hosts the Windows Firewall, the Base Filtering Engine, and the Diagnostic Policy Service. It also uses a write restricted token, which will be discussed in Chapter 6. On the Web site for the book (http://www.wiley.com/go/windowsvistasecurity) you will find a document that lists security parameters for every service that ships with Windows Vista Ultimate Edition. Based on the findings outlined in that document, only nine services currently use RESTRICTED and write restricted tokens in Windows Vista.

As with recent previous versions of Windows, the best practice with respect to registry permissions is to tread very carefully. Except for in exceptional, and highly targeted, circumstances, do not modify permissions in the registry. Given the complicated inheritance model and the sensitive operations performed on the registry, you run an unacceptably high likelihood of fatal failure if you modify ACLs in the registry carelessly.


Summary

Windows Vista makes a number of interesting changes to ACLs. Many of these changes are in support of other features, such as service hardening and UAC, and result in a somewhat different experience when managing ACLs from previous versions of Windows. There is also a new tool, icacls, for managing ACLs. Anyone who is serious about managing ACLs, however, needs to spend some time with subinacl, which is far more powerful than any prior Microsoft tool for managing ACLs. It is also the only command-line tool for managing registry ACLs. icacls does have a very nice feature to reset permissions to inherited permissions, which does not exist in subinacl. It is well worth becoming familiar with both tools.


Best Practices

  • Learn to use icacls and subinacl.

  • Become familiar with how OWNER RIGHTS works.

  • Explore and understand the new default permissions.

  • Learn SDDL if you do not already know it.

  • Do not modify permissions on built-in objects except for in very targeted and narrow circumstances. KB article 885409 still applies. Changing the default permissions on a single file to offset a zero-day vulnerability is rarely an issue and can often be very useful. You can even do this with a startup script. Modifying the ACL on the root of the C: drive because you want to use Authenticated Users instead of Built-in Users is almost certainly going to destroy your system and will certainly leave you with an unsupported and unsupportable system. The more you understand about how permissions work, the less likely you are to get yourself into trouble and the less likely you are to use wholesale permissions changes in the first place.


Chapter 6: Application Security

Windows Vista changes several things with respect to applications and how they run. We looked at the most notable change, User Account Control (UAC) in Chapter 4. For developers, these changes require rethinking how you write applications. For system administrators, it means rethinking how you use them. This chapter is about how applications work on Windows Vista. Some parts are geared more to developers and some administrators who write their own code. Most of it should be of general interest to administrators who want to know how applications behave differently on Windows Vista. We also make good on the promise we made in Chapter 4, and show how to make an arbitrary application invoke the UAC prompt on launch.

Windows Vista makes some very fundamental changes in how applications run on top of it. It is difficult, therefore, to structure a chapter logically that describes it. In some ways, this chapter may seem like a grab bag, and it is. It covers technologies that did not merit their own chapter, but that all are important in their own right.

Client Security

The security of a client (as well as a stand-alone) computer is dependent on a large number of factors. Of course, the security of an individual computer depends for its security on the entities that control that security: the domain controller (DC) and the domain administrators, as well as any local administrators.

In addition, the security of the client depends in large measure on the applications running on that client and how they are running. In this section, we will look at a number of things done to make the clients in your organization not just more secure, but more stable as well. As we all know, you cannot be stable if you are not secure, although you can of course, be secure without being stable.

Service Hardening

We mentioned in Chapter 5 that most of the Operating System (OS) binaries are now owned by the TrustedInstaller service and can only be modified by that service. It is not just the TrustedInstaller service that can be granted access to objects in that way. Any service, in fact, can have a unique Security Identifier (SID) and can be granted access in the same way. This is part of a technology called "Service Hardening." Service hardening consists of several features.

Service SID

Each service can now, just like the TrustedInstaller, be represented by its own service SID, uniquely identifying that service. This means that you can grant or deny access to any securable object to a specific service. This is a radical departure from previous versions of Windows. In those versions, the service was identified only by the process token of the process within which it ran. That process could contain 10 or 20 services in extreme cases, and every one of those services would have access to all the things that process had access to, as would any service in any other process that was running in the same user context! This made it effectively impossible to restrict access to only an individual service.

Service SIDs change all that. Service SIDs are deterministic and based on the name of a service. That means that if you are writing a service and want to know what name it will have, you can generate the SID before you even start. To see what the SID would be, use the SC command-line tool:

     C:\>sc showsid
     DESCRIPTION:
             Displays the service SID string corresponding to an arbitrary
             name. The name can be that of an existing or non-existent
             service.
     USAGE:
             sc showsid [name]

     C:\>sc showsid foobar

     NAME: foobar
     SERVICE SID: S-1-5-80-3259854826-3107389163-894102390-594757917-   Image from book
     2872763584

If you are writing code to find Service SIDs you can find them with LookupAccountName using "NT SERVICE" as the domain and the service name as the account name. However, LookupAccountName will fail unless the service actually exists.

Services Running with Less Privilege

In Windows NT 4.0 and Windows 2000 every built-in service ran as Local-System. In Windows XP, a few ran in the less privileged NetworkService and LocalService accounts. Both of those latter accounts represent the computer, but they have fewer rights than the LocalSystem account. The difference between NetworkService and LocalService is that NetworkService can authenticate to network resources as the computer.

In Windows Vista, many of the services that ran as LocalSystem in Windows XP have been moved to either LocalService or NetworkService. There are 42 services running as LocalService in Windows Vista, compared to 12 in Windows XP; and there are 18 running as NetworkService, compared to 7 in Windows XP. (Note that the exact number of services in each context differs with the version of the OS. These numbers were generated on Windows XP Media Center Edition and Windows Vista Ultimate.) Unfortunately, so many new services have been added that the number of services using LocalSystem is 69 in both cases. Of course, the majority of those services are not actually running in a default installation.

One very interesting example of a service moved to a less privileged context is the Workstation service, which ran as LocalSystem in Windows XP, but as LocalService in Windows Vista.

Reduction of Privileges in Services

In addition to moving services to less privileged context, many of the services also run with restricted tokens that have almost all their privileges removed. For example, the Remote Procedure Call (RPC) Endpoint Mapper service in Windows XP has the following privileges and rights:

  • SeAssignPrimaryTokenPrivilege

  • SeAuditPrivilege

  • SeChangeNotifyPrivilege

  • SeCreateGlobalPrivilege

  • SeImpersonatePrivilege

  • SeIncreaseQuotaPrivilege

  • SeShutdownPrivilege

  • SeUndockPrivilege

Figure 6-1 shows a screenshot of the security token on the RPC Endpoint Mapper under Windows Vista.

Image from book
Figure 6-1: Security token for RPC Endpoint Mapper on Windows Vista

As you can see from Figure 6-1, the token for the RPC Endpoint Mapper has only three privileges left in Windows Vista:

  • SeChangeNotifyPrivilege

  • SeCreateGlobalPrivilege

  • SeImpersonatePrivilege

If done properly, this type of service factoring provides significant security benefits. Therefore, we highly encourage everyone to demand the same of Independent Software Vendors (ISV) for services that you purchase. There should be little reason to write services with the high-level privileges we are used to seeing in them. However, nothing will change unless customers demand it. Microsoft cannot make ISVs do the right thing, and we, as authors, can only attempt to shame them. However, if all of us refuse to purchase software that is poorly written and poorly secured, things can change. We encourage you to visit a Web site called Threat Code (http://www.threatcode.com) at some point in your purchasing process. It lists applications that commit egregious security mistakes and can help you avoid spending money on insecurable software. If an application shows up there, we highly recommend you evaluate options rather than reward vendors for not building software that can run securely.

For programmers, the Change/QueryServiceConfig2 Application Programming Interfaces (API) support a new set of flags that allow you to configure the token the service should run as, the privileges it needs, and additional restrictions based on its service SID. One of the restrictions you can configure is to write-restrict its process token.

Write Restricted Tokens

Services can run with a write-restricted token. A write-restricted token can only be used to write objects that grant explicit access to the service SID. Unfortunately, this functionality is not used as much as it potentially could be at the moment. The following 9 of the 150 built-in services use a write-restricted token:

  • Base Filtering Engine

  • Diagnostic Policy Service

  • Net.Msmq Listener Adapter

  • Net.Pipe Listener Adapter

  • Net.TCP Listener Adapter

  • Net.TCP Port Sharing Service

  • Performance Logs & Alerts

  • Windows Firewall

  • Windows Media Center Service Launcher

Firewall Policies Restricting Services

As we will discuss in Chapter 11, firewall policies can be configured per user. Because services are now real users, they can be granted, or denied, permission to connect out or accept inbound connections through the firewall as well. This feature, in fact, is what makes it meaningful as a security feature to use outbound filtering on host-based firewalls in Windows Vista. More about that will follow in Chapter 11.

Named Pipes Hardening

A named pipe is a type of Inter-Process Communications (IPC) mechanism. You can think of a named pipe as a virtual file which allows two processes to hold it open and read and write to it at the same time. A server process that needs data from a client could create a named pipe and then instantiate that pipe to create a pipe instance. A client process that needs to pass data to the server process can then open the named pipe instance and write data to it. The APIs used to read and write named pipes are the same as those used to read and write files, making named pipes a simple and convenient mechanism for IPC.

Named pipes are often used by services to receive data and in those cases, the actual transport used between the server and the client is very often RPC. As part of the general service and RPC hardening that Microsoft has done in Windows Vista, they have also hardened named pipes that use RPC as the transport.

Services often run as individual sub-processes within a larger process. As Figure 6-2 shows, there could be a large number of services in a single process.

Image from book
Figure 6-2: A single service process can host many services.

In Windows XP the Access Control Lists (ACL) on a named pipe created by any of those services granted the right to create pipe instances to the process identity, which is NetworkService in Figure 6-2. In Windows XP, there was no infrastructure for restricting that right at a more granular level. In Windows Vista, the Service SID is used to allow only the individual service to create named pipe instances. This makes it more complicated for a compromised service from hijacking a named pipe from another service running in the same process. It is not foolproof, but it is one more step toward the end goal of insulating services from failure in other services.

This functionality is also available to third-party services. As mentioned, we highly recommend requesting your ISVs to opt in to using the same functionality.

Windows Resource Protection

Windows Resource Protection (WRP), as we mentioned in Chapter 1, is the new name for Windows File Protection (WFP). This name, however, does not really do it justice though. Unlike WFP, which only protected certain files, WRP protects much, much more.

First, almost 70 percent of the files in the Windows directory are now protected by WRP. This is a big improvement over the protection rate of about 12 percent in Windows XP.

Second, WRP protects files primarily using ACLs. Roughly 7,000 files are protected using an ACL Entry (ACE) that allows only the NT SERVICE\ TrustedInstaller service to modify those files. This includes all files with a .dll, .exe, .ocx, .sys, .com, .vbe, and about 50 other extensions that are installed by Windows Vista.

Third, contrary to WFP, WRP protects registry keys in the same way that it protects files-by marking them modifiable only by the TrustedInstaller service.

Finally, WRP uses its cache differently than WFP. In WFP, all protected files are cached in %systemroot%\System32\dllcache. WFP attempts to detect whether a protected file is modified by getting notified of any changes to the files. Upon a change it compares the hash of default data stream in the existing file to its stored value. If the two do not match the existing file is replaced by the copy in the cache directory. A favorite trick by malware was to modify both versions of the file, including the one in the cache directory. WRP, by contrast, does not cache all the files it protects. It caches only those that are needed to start Windows. These files are stored in %systemroot%\winsxs\backup\. This cache directory is considerably smaller than the one on Windows XP because fewer files need to be in there. This reflects an acknowledgement that the primary method for protecting system files need to be built-in security measures, not making two copies of them for malware to modify.

WRP reflects a new way to think about how to stabilize a system. In a way, it is a return to basics, to tried and true security measures, such as ACLs, enabled by new technologies such as service hardening. It also means that developers need to rethink how they use the system. They cannot modify OS files at will. Obviously, an administrator can change the ACL on a protected resource and modify it. However, not only will this generate a UAC prompt, Microsoft is also using the Windows Logo program to prevent legitimate programs from doing so other than through Microsoft-provided redistributable packages. This is designed to prevent ISVs from destabilizing a user's system, as has been done so many times in the past. There are also Application Programming Interfaces (API) that ISVs can use to verify whether a file is protected or not. SfcIsFileProtected and SfcIsKeyProtected, respectively, will return true if a file or registry key is protected. For more information on Windows Resource Protection, see http://www.msdn.microsoft.com/library/en-us/dnlong/html/AppComp.asp?frame=true#appcomp_topic6.

This actually has an important security implication. Previously, it was quite common for ISVs to decompose Microsoft's redistributable packages and install them together with their own applications. In many particularly egregious cases only a portion of the redistributable package was installed. This made servicing of the packages practically impossible. You were no longer using a complete set of Microsoft's components, and if you were, an update installer would likely not recognize that you were and would not be able to patch them. This caused severe grief during several worm outbreaks. For example, one author remembers having a meeting with an ISV over four weeks after SQL Slammer came out. The ISV wanted to know how to patch the version of Microsoft SQL Server Desktop Engine (MSDE) that they had distributed to thousands of customers on five continents. Because they had repackaged the Microsoft package, the Microsoft provided package installers did not work-something which the ISV had only realized after SQL Slam-mer took down their internal test bed. Their software was used to run critical infrastructure, and for all practical purposes, it could not be patched because they had modified Windows system files using a non-approved process.

Clearly, Microsoft keeping a tighter grip on its own components is a boon to stability and serviceability and a benefit to IT Pros everywhere. Not surprisingly, the ISV community is not nearly as enamored with it. Then again, we know that large portions of the ISV community refuse to understand that security is important and is their concern as well.

Session 0 Isolation

Windows Vista includes one particularly fundamental change to how user's applications run, called Session 0 Isolation. To understand this, you first need to understand the concepts of sessions, window stations, and desktops.

Sessions

The easiest way to understand sessions is to consider a terminal server. Each user that logs on to a terminal server gets her own session. This session contains everything that this user sees, including the user's desktops (there may be several) all the windows, and so on. The sessions are numbered from 0 to n. A terminal server supports several interactive sessions. Windows XP supports several, as well, but only under Fast User Switching (FUS). On Windows XP, only one of these can be active at a time.

The first interactive session on Windows XP is created when the system boots. It is called session 0. It is an interactive session and is assigned to the first interactive logon on the system (if FUS is enabled) or the interactive logon (if FUS is not used). In addition, in session 0 you will find all services

Window Stations

Each session contains a collection of Window Stations (winsta). The window stations are essentially containers that hold windows the user sees, the clipboard, and so on. They are also numbered starting at 0. Only WinSta0-the first window station created in each session-can access certain input/output (I/O) devices, such as keyboards, mice, and the screen.

Desktops

Finally, we have desktops, which are logical display surfaces hosting windows, menus, and other objects the user can interact with. A single window station may have several desktops, and a single session may have several window stations. This is depicted in Figure 6-3.

Image from book
Figure 6-3: Sessions can have multiple window stations, which can have multiple desktops.

Why Session Isolation Is Needed

As Figure 6-3 shows, there is some level of isolation between desktops in the same window station, and between window stations in the same session.

However, as security bulletins MS02-071 (http://www.microsoft.com/technet/security/bulletin/MS02-071.mspx) and MS00-020 (http://www.microsoft.com/technet/security/bulletin/MS00-020.mspx) show, the isolation was insufficient. Mechanisms were found which allowed applications on different desktops in the same window station to communicate with each other. Where those applications were running in different privilege levels this created a local privilege escalation path by means of sending window messages from an unprivileged process to a privileged window on the same desktop or in the same window station. These types of security issues eventually received the name "Shatter attacks," coined by Chris Paget, to denote an attack that "shattered" a window.

Shatter attacks were a problem only if there were privileged applications running on the same desktop as unprivileged applications. Unfortunately, several Windows Services, and literally thousands of third-party services did this. Putting Windows on the interactive desktop was an extremely common way to communicate with the user because it was considerably easier than properly architecting process isolation into a service.

When Microsoft reviewed this type of attack during the design of Windows Vista, it was discovered that it was architecturally impossible to properly isolate high-privileged processes on the same desktop as unprivileged ones. This is where Session 0 isolation came from.

How Session 0 Isolation Works

As mentioned earlier, in Windows XP, all the services run in session 0 along with the interactive user's desktop. In Windows Vista only services run in session 0. Session 0 is also non-interactive. The interactive user's desktop runs in a different session. The first user receives session 1, the second user session 2, and so on.

Session 0 isolation will have a certain application compatibility impact. However, the applications affected by it are primarily services that do things they should not be doing anyway: throw interactive UI on an interactive desktop. One easy way to visualize this problem is with a service that throws up a dialog box on the interactive desktop and then waits for the user to respond to the dialog box. On Windows Vista, this dialog box will never show up and the user will not provide the input. The net result is that the service appears to hang.

There are some ways to mitigate this problem. The best one is for each ISV to redesign their services properly. Instead of having the service throw interactive UI, the service should be split into a service and a user component. The two may communicate via some IPC, such as RPC. This allows the user component to throw UI and get input from the user.

For the individual end user or system administrator, the work-around is not so simple. Some things simply cannot be made to work. For applications with an interactive component, try running the application in Windows XP compatibility mode (set on the property sheet for the exe file) instead. This allows the application to interact with the session 0 desktop. If the application tries to communicate with a service using previously allowed mechanisms, this may allow it to function.

You may also use the Interactive Service Detection Mechanism. This is a service which sits in session 0 and attempts to detect interactive messages and notify the users in other session. A user is then given the option of switching to session 0, where she can respond to the UI, and then switch back to her own desktop. The Interactive Service Detection Mechanism is not started by default, but can be changed to automatic either in the Services snap-in or even using Group Policy if need be. It should be pointed out that any service the Interactive Service Detection Mechanism finds to pop interactive UI is broken by design according to Windows Vista's architecture guidelines. It should be replaced with a properly designed service as soon as such a service is available.

There are additional mitigations for possible application compatibility problems as well. For more information, see http://www.microsoft.com/whdc/system/vista/services.mspx.

Note that session 0 isolation hints at one of the reasons we do not consider UAC to be a security solution. By definition, elevated applications are privileged applications running on the same interactive desktop as unprivileged applications. This makes them potential targets for a privilege escalation attack. Many of the avenues for such attack were closed by Microsoft. However, it is possible, even likely, that some remain. This is why, in Chapter 4, we recommended not elevating applications within an unprivileged session if at all possible. The safest method still remains to use Fast User Switching (FUS) to log on as a privileged user in a privileged session. This ensures complete separation between elevated and non-elevated applications.

Reducing the Footprint

If there was ever one primary criticism of Windows 2000, it was that it came with everything including the kitchen sink installed by default. Particularly the server versions were provisioned with a lot of things, such as the service that allowed you to publish printers to arbitrary hosts on the Internet via IIS. This became a much worse idea right about the time when a massive buffer overflow vulnerability was found in that service.

To address this issue Microsoft has been refactoring many components to allow certain things to be optional components and also removing things that are rarely used. Some items are gone. For instance, while Windows XP and Windows Server 2003 both shipped with three different versions of Windows Media Player installed by default (5.2, 6.4, and 9.0 on Windows XP and 10.0 on Windows Server 2003); Windows Vista ships with only one (version 11).

What is installed by default, and available for installation, depends on the exact edition of Windows Vista you are using. These comparisons were made using Windows Vista Ultimate and Windows XP Pro Service Pack 2.

We highly recommend that system administrators use what we have here only as a basic overview and evaluate the footprint of their specific installation and what they wish to be part of it.

No Longer Installed by Default

A number of other items we are used to seeing installed by default have also been made optional, as follows:

  • Telnet client: The telnet client was not used by the vast majority of users. Therefore, it was made optional.

  • Telnet server: The telnet server was installed but not started by default in Windows XP.

  • POSIX subsystem: The POSIX subsystem was removed entirely from Windows XP. In Windows 2000, it was installed by default. In Windows Vista, it is part of an optional component called Subsystem for Unix based applications. Making this a separately installable component gives administrators much more control over where it is used.

  • TFTP client: The TFTP client was installed by default on every computer running Windows; until Windows Vista came out that is. In Windows Vista, the TFTP client is finally optional.

Gone Altogether

Just like some things are now optional installs, some things are gone altogether, although in some cases they are replaced with other things.

  • MSN Explorer: There is apparently no such thing any longer.

  • Windows Messenger: Windows Messenger has been deprecated. It is being replaced by Office Live Communicator, while MSN Messenger has been renamed to Windows Live Messenger. This is important for security as many organizations attempt to block messenger services. by blacklisting executables. Naturally, doing so is an ineffective way to control instant messaging traffic.

  • NetMeeting: NetMeeting has been on life support, and pretty weak life support at that, for quite a while. In Windows Vista, it has been replaced with Windows Meeting Space. Many of the features are similar to Net-Meeting, including the ability to share the desktop and transfer files. For that reason some organizations will love this feature as an inexpensive collaboration solution, while others will certainly want to prohibit it entirely. If you wish to disable use of Windows Meeting Space you can do so with Group Policy. The settings are under Computer Configuration:Administrative Templates:Windows Components:Windows Meeting Space.

  • Hyperterminal: The venerable terminal emulator is now gone. Microsoft never owned the source code for Hyperterminal and when a vulnerability was discovered in it, this became a problem. Probably owing in no small measure to the security bulletin it had to issue for Hyperterminal, Microsoft removed it altogether from Windows Vista. The recommendation is to use the telnet client instead, but that only replaces the telnet functionality in Hyperterminal. Customers in need of a terminal emulator will have to look elsewhere.

Added Instead

There are also some new components installed by default. Some of these were optional in Windows XP, and quite a few others did not exist on Windows XP SP2.

  • Windows Fax and Scan service is installed by default on Windows Vista, whereas it was optional on Windows XP SP2.

  • Windows Meeting Space is the replacement for NetMeeting.

  • Several DVD Player components are included by default in Windows Vista. Windows XP had no built-in support for playing DVDs.

  • Tablet PC Optional Components: These are installed on some additions of Windows Vista automatically, whereas they were only present in the Tablet PC Edition of Windows XP.

  • Windows Sidebar: This is a new component that puts a strip of components on the right-hand side of the monitor by default. It can be a very interesting productivity tool. However, given that it renders HTML it could conceivably be an attack vector as well. It also runs with medium integrity, contrary to Internet Explorer (IE) itself, which runs with low integrity. At this time we have no indications that this is a problem, but it is something worth paying attention to.

It Should Have Been Gone

It is a bit flippant of us to say that certain things really should have been removed because we, by necessity, do not have access to the usage data that Microsoft does, and when your software is used by 800 million people in everything from fuel pumps to stock brokerage, things change a bit. Nevertheless, there are some things we really wish were gone.

  • Debug.exe: The 16-bit debugger is still present on the 32-bit version of Windows. It is not there on the 64-bit version because it does not have a 16-bit subsystem. The theory is that Microsoft's support services use the debugger to troubleshoot problems and it is too much trouble to install it when needed. Instead, everyone gets to have it. A regular user can only debug programs they already own, and of course, they could add a debugger, so there really is no risk from that perspective to having it there. However, if malware manages to run a shell command on a compromised computer, the debugger can be used to transfer files down to the computer with no additional tools installed. Of course, malware can run shell commands a lot of things have already gone wrong, so you need to take the risk with a grain of salt.

  • Edlin.exe: We just have to ask: why? What possible use could anyone have for edlin these days? And, if you have no idea what edlin is, it is a line-oriented text editor that originated in the early versions of DOS, before there was Windows, or even edit.exe.

  • Edit.exe: While we are on the topic of text editors, it is slightly more likely that someone is going to use edit, but if you are the type to use character based text-editors you would probably just download a Win32 port of vi-the editor of the gods-and not bother with the wysiwyg-wannabe edit.exe. (If you don't know what wysiwyg means, count your blessings.)

  • At.exe: Yes, a command line scheduler is needed, but can't we get a command line version of task scheduler instead?

  • Finger.exe: Does anyone run fingerd any more?

As we mentioned earlier, the issue of deciding what needs to be included and what can be dropped is very complicated. It spans geopolitical, product marketing, and technical concerns. From that perspective, security is a late entrant to the considerations. We like the fact that Microsoft did remove a few things by default, and we hope it can go further in future versions of Windows. We encourage administrators to look at what they have installed and disable use of features they do not need.


Restart Manager

One of the primary complaints in the early versions of Windows NT was that it needed far too many reboots to be a viable enterprise operating system, particularly for servers. Those of us who had installed binary patches on VMS years earlier could not figure out why Windows NT needed so many reboots. In Windows NT 4.0, you could not even change an IP address without rebooting (according to the documentation).

In Windows 2000, Microsoft started a push toward minimizing the number of reboots the OS required. The community had mixed feelings, and at least for a time there were Web sites that tried to track uptime on individual servers on http://www.microsoft.com in an effort to discredit Microsoft and demonstrate that you could not keep Windows NT up consistently. Nevertheless, the number of reboot-required scenarios did decrease and the one that remained consistently was patching. Each time an update-usually of the security persuasion-was applied, the system typically needed a reboot, even for things that did not seem essential, such as IE.

To address this remaining set of required reboots, Windows Vista introduces the Restart Manager. Restart Manager is quite simple conceptually. Many applications and/or services need to be shut down to be updated. In the absence of an automatic way to do so, a trick used by some was to shut down just the service, install the update for it, and then restart the service. This avoided the reboot that would normally have been needed to update the service if it were running. Restart Manager essentially incorporates that functionality into the Windows Installer infrastructure. It will be able to update Applications that are written to take advantage of Restart Manager, or written to be installed and updated using Windows Installer, without a reboot in most cases. Restart Manager will automatically save the state of the application, shut it down, update it, restart the application, and restore its state in memory as it were before the operation. Windows Installer and Restart Manager can update normal user applications, services, and even the Windows Explorer shell this way. Only certain services judged critical to the computer's functioning are exempt:

  • smss.exe: The Session Manager sub-system

  • csrss.exe: The Client-Server run-time sub-system

  • wininit.exe: The Windows start-up application

  • logonui.exe: Windows logon user interface host

  • lsass.exe: Local Security Authority shell

  • services.exe: Services controller application

  • winlogon.exe: Windows NT Logon application

  • System: The operating system kernel

  • svchost.exe with RPCSS: The service host hosting the RPC Sub-System

  • svchost.exe with Dcom/PnP: The service host hosting the DCOM sub-system

While this feature will not eliminate reboots entirely, it will certainly reduce the number needed when Windows Vista needs patching. That in turn will improve uptake on security updates, thus providing a net security gain.

For more information on the Restart Manager, and information on how to write applications to take advantage of it, see http://www.msdn2.microsoft.com/en-us/library/aa373654.aspx.


ActiveX Installer Service

ActiveX was introduced with IE many years ago to allow developers to include active content in a web page. It was a competitor to Netscape's plug-in technology and eventually won that battle. A battle ActiveX never quite managed to win, even though it, by and large, was the only competitor until things such as Shockwave and Flash (which were actually implemented as ActiveX objects) showed up, was security. The thought of web pages provisioning content to be run unfettered on a user's computer made just about everyone nervous, and in order to install the controls, users had to be administrators. There is no way to install controls per user.

In Windows XP, and particularly in SP2, some additional controls were introduced for ActiveX controls, and these controls have been expanded in Windows Vista.

The ActiveX Installer service is nominally a part of UAC (see Chapter 4). This is quite logical if one considers that one of the primary benefits it provides is that users no longer need to be administrators to install ActiveX controls. To use the ActiveX Installer Service an administrator first enables the service, which is included on the Business, Enterprise, and Ultimate SKUs of Windows Vista. After that you would use the Group Policy Administrative Template, under Computer Configuration:Administrative Templates:Windows Components:ActiveX Installer Service to configure which hosts users can install controls from.

To configure the ActiveX Installer Service you need the exact host URL where the ActiveX control is hosted. If you do not know that you can get it by taking the following steps while logged on as a standard user on a computer where the ActiveX Installer Service optional feature has been installed:

  1. Open a web browser.

  2. Navigate to a page that tries to install the control you want.

  3. Click the yellow ribbon to install the ActiveX control.

  4. Cancel the UAC elevation prompt.

  5. Open the Application Event Log and search for event ID 4097 from the ActiveX Installer Service.

  6. The event data includes the URL that the control came from.

Perhaps the best way to use the ActiveX Installer Service is to capture a set of controls that your users are trying to install on their computers. You can then use this list to develop a list of your own controls that you want them to install without elevation.

Unfortunately, documentation on the ActiveX Installer Service is extremely terse at the moment, and the configuration of the GPO is obscure to say the least. There are some articles, including one in TechNet Magazine, that mention it (http://www.microsoft.com/technet/technetmag/issues/2006/11/UAC/default.aspx). However, in aggregate they make it seem as if you simply enable the policy with a single click. To really make use of this feature you need to understand the relatively obtuse configuration interface. It consists of a name/value pair, where all the values have defaults. The name is the URL of the ActiveX control you wish to allow your users to install. The value is a comma-separated list of four possible values.

  • Installation behavior for controls signed with a cert chaining to a root cert in the trusted publishers store. Default value is 2.

  • Installation behavior for controls signed with an untrusted cert. Default value is 1.

  • Installation behavior for unsigned controls. Default value is 0.

  • Policy for how to handle HTTPS validation of the download site, if it uses HTTPS. Default value is 0.

After configuring the ActiveX Installer Service to allow users to install the Adobe Flash Player and to verify the certificate on the site, you would create a setting in Group Policy as shown in Figure 6-4.

Image from book
Figure 6-4: The ActiveX Installer Service configured to allow you to install the Adobe Flash Player

The first three values in the comma-separated value list can take on a value of 0, 1, or 2. 0 means "fail the installation." 1 means "prompt the user and install if the user decides to do so." 2 means "succeed." The final value can take a bitmask to control how to validate certificates for an HTTPS download. If you leave it at 0, which is the default, all validation will take place. You can configure it to ignore some components of the validation, but it is highly recommended that you do not do so. Unfortunately, many vendors, such as Adobe, as shown in Figure 6-4, do not provide an HTTPS download link for their ActiveX controls. For that reason, we highly recommend organizations host controls internally on trusted servers and only allow installation from there.

With the settings made, as in Figure 6-4, a standard user can go to any Web site that installs the control from the approved sites and install it without needing administrative credentials. Instead of an elevation prompt, the user gets a simple warning from the ActiveX Installer Service, as shown in Figure 6-5.

Image from book
Figure 6-5: After the ActiveX Installer Service has been configured to allow installation, the user gets a simple installation dialog box.

It is worth noting here that the ActiveX Installer Service works for non-administrators only. Members of the Administrators group still require a UAC elevation to install ActiveX controls. The policy does not affect them.

As a final note, it is extremely important to remember that the ActiveX Installer Service does NO validation on the control itself. The only validation is that it is signed, and, if the site providing it supports it, that the connection uses HTTPS. For this reason we highly recommend that you either provision controls only from sites that can authenticate themselves using HTTPS, or only authorize controls signed with trusted certificates, or both. Your organizations personal level of paranoia will decide which set of options you use, but configuring the ActiveX Installer Service with a "2,0,0,0" value combination seems perfectly reasonable.


Antivirus

A constant sore point in security is anti-virus programs. Interestingly, in a clean default installation of Windows Vista, Security Center will show a yellow severity warning because there is no antivirus program installed by default.

Opinions on anti-virus programs are mixed. According to the anti-virus vendors they are the panacea that will save the world from certain destruction. According to at least one of the authors, they are leading us to believe that we are far safer than we really are and cause us to fail to focus on the actual problem: protecting users from attacks that are increasingly not signature based and increasingly targeting them: the users (http://www.microsoft.com/technet/technetmag/issues/2006/07/SecurityWatch/default.aspx). According to at least one Microsoft exec, Windows Vista is so secure you do not need antivirus, while another asked the bad guys to "bring it on." Most rational people, including both authors, still acknowledge that anti-virus programs generally should be installed on most computers, although for many it was also a very long time since they last had one actually find a real virus.

64-bit versions of Windows Vista were a bit of a concern in this department for a while. However, by the time you read this, most of the popular anti-virus programs should be offering versions for both 64-bit and 32-bit versions of Windows Vista.


Desktop Optimization Pack

The Microsoft Desktop Optimization Pack (MSDOP) is an add-on available to Microsoft Software Assurance (SA) customers. Strictly speaking, it is not part of Windows Vista although it is available to customers with SA coverage including Vista. MSDOP contains four different technologies, three of which are really interesting from a security perspective.

The first is Microsoft SoftGrid, which Microsoft acquired in the Softricity acquisition (http://www.softricity.com/index.asp). SoftGrid allows users to run applications on their computers without actually installing them first. The applications are provisioned to the clients when the user runs them.

That is not the most interesting aspect of SoftGrid, however-at least not from a security perspective. The really interesting part is that applications run within a virtual environment on the individual PCs. While being virtualized they can read some pieces of the registry, but not write from them, and they are essentially unaffected by other applications on the same computer! In a blog post, Kevin Sullivan shows a screenshot where he is running PowerPoint XP and PowerPoint 2003 at the same time (http://www.blogs.technet.com/kevinsul_blog/archive/2006/09/06/454467.aspx). Normally that is not possible. This could be important if you need to run applications that require loosened security to run properly. If you can virtualize either that application, or other applications, or both, using SoftGrid you may be able to keep those changes from affecting other applications.

The second technology that is interesting from a security perspective in MSDOP is some additional Group Policy administration tools. The Microsoft

Advanced Group Policy Management toolkit allows you to better implement change management and rollback for Group Policy. It also implements a better administration and delegation model that permits role-based access control for Group Policy management.

Finally, the Microsoft Diagnostics and Recovery Toolset is a Windows PE-based recovery toolset used to diagnose and repair unbootable or locked-out systems. For instance, it can be used to remove malware from a system without your having to boot it into the infected installation. You can cobble together your own kit to do malware removal using Windows PE, however. In Appendix A, we show you how to build a bootable USB flash disk with Windows PE. If your favorite anti-malware tool can run within that environment you can use that to diagnose your system.

For more information on the MSDOP, please go to http://www.microsoft.com/windowsvista/getready/optimizeddesktop.mspx. Note that at the time of this writing, the MSDOP is not yet available in final form.


Summary

This chapter has provided an overview of a number of technologies shipping either in Windows Vista, or closely related to Windows Vista, that affect security of your desktops. Many of these are technologies that are just "there" for you to take advantage of with no additional configuration needed. However, many, such as the Restart Manager, Session 0 isolation, and Service Hardening, need to be leveraged by your application vendors to realize their full potential. Some require you to configure them properly to realize any benefit at all. These include the ActiveX Installer Service and the MSDOP. Used properly, these technologies can all be valuable tools in your quest to protect your network.


Best Practices

  • Use a standard user account as your information worker day-to-day account so that you can understand how to better provide needed services for your users who (should) run that way already.

  • Make implementation of Service Hardening a factor in application purchasing decisions. Insist that your vendors implement similar technologies in their products.

  • Make technologies such as Windows Installer 4.0, which minimizes reboots and eases patching, factors in application purchasing decisions.

  • File a complaint with any vendor that does not provide an HTTPS download site for their ActiveX controls.

  • Investigate which ActiveX controls are used on your users' desktops and provision them using the ActiveX Installer Service.

  • Make all your users standard users and teach them how to install ActiveX controls using the ActiveX Installer Service.

  • If you are a Software Assurance (SA) customer, investigate whether you can leverage the MSDOP to provide lower Total Cost of Ownership, better manageability, and higher security. Even if you purchase OEM systems you can add SA coverage within 90 days of the purchase, and you need only five units to get it.


Chapter 7: Vista Client Protection

Windows Vista is designed to prevent the local execution of malicious mobile code. Chapter 7 discusses Microsoft's newest initiatives against malware programs, including the Malicious Software Removal Tool, Security Center, Windows Defender, Windows Live OneCare, and Microsoft Fore-front Client Security.

Popularity of Client-Side Attacks

Client-side exploits are always a popular type of malicious attack. However, the present focus on using them for profit is unprecedented. The Microsoft Antimalware Team revealed the following statistics in a free white paper (http://www.microsoft.com/downloads/details.aspx?FamilyId=&displaylang=en) based upon the results from Windows Malicious Software Removal Tool (MSRT), which ran over 2.7 billion times on over 270 million unique computers. Some of the findings are as follows:

  • High-risk malware is found on 1 in 311 computers (i.e., 5.7 million computers)

  • 3.5 million computers had a backdoor Trojan (or 62 percent of infected computers)

  • 9 percent of infected computers had a malicious rootkit

  • Bots (Rbot, Sdbot, and Gaobot) compromise three of the top five popular malicious removals

The detection rate of malicious software (1 in 311 computers) is drastically lower than the overall malware prevalence rate because MSRT does not check for spyware, adware, phishing e-mails, malicious links, and any malware not present in memory (for example, script worms). In light of these findings, it's likely that nearly 100 percent of computers should be considered exposed to malware. However, much of that malware does not remain resident on the computer. For instance, phishing e-mails generally do not infect the computer but prey instead on the user using the computer. The MSRT looks only for the most popular and critical technical threats. Therefore, it greatly underestimates the prevalence of attacks as a whole. When the single category of spyware is added in, for instance, some vendors report that over 80 percent of all consumer PCs are infected (for example, http://www.webroot.com/company/pressroom/pr/state-ofspyware-Q206.html?WRSID=298b2c998c8805c226e2036d13c1d090).

Note

We would caution you to take any number or statistic from an anti-malware vendor with a grain of salt, however. Anti-malware companies may not see the whole universe of computers, and in any case, they have a vested interest in the numbers appearing as bad as possible. They will sell few copies of their software if the numbers look nice and rosy. Also, Microsoft may be considered as having a vested interest in making the numbers look better than they should, as a bleak picture threatens their eco-system. Therefore, the truth may lay somewhere in between what Microsoft says and what the anti-malware vendors say. The actual number is probably irrelevant, however, and is fluctuating all the time regardless. Notwithstanding any concerns about the specific statistics, it is clear that malware infections are at epidemic proportions.

Over half of all e-mail is spam and 1 in 200 contains malware (http://www.messagelabs.com/publishedcontent/publish/threat_watch_dotcom_en/intelligence_reports/august_2006/DA_173428.html).

Microsoft recommends all personal computer users run antivirus software, anti-spam, anti-spyware, and other software defense tools.


Malicious Software Removal Tool

The Malicious Software Removal Tool was first released in January 2005 to detect and remove the most popular malware families. Although not a default part of Vista, Windows users can expect to see MSRT show up more and do more. Microsoft initially created it to quickly remove common malware threats in response to current attacks and before new Microsoft software was installed. One of the most common reasons a Microsoft software install or upgrade fails is because of installed malware. The end user doesn't realize they have malicious programs installed, and instead blames Microsoft for the installation error. In at least one case, a spyware program tried to prevent its own removal, thereby destroying the installation of Windows XP Service Pack 2. The result was that the computer would irrevocably crash on the first reboot after installing Service Pack 2. Even a safe-mode boot would not work to restore it. By first checking for and removing common malware, Microsoft has decreased the install failure rates for end users.

MSRT is free and can be downloaded from http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=, but it normally downloads, runs, and then uninstalls before significant Microsoft installs and updates. It downloads and runs monthly using Automatic Updates, Windows Update/Microsoft Update, or Windows Server Update Services. Normally, an end user license agreement (EULA) must be agreed to the first time MSRT is run. The automated versions run in the background, and are almost unnoticeable unless an infection is found. The separate stand-alone version may be downloaded and installed to run on-demand scans.

Note

Users running the manual version must be logged in with Administrator credentials. As the version distributed via Microsoft Update runs as a normal Windows Update, it does not require any special privileges to run.

Currently, each version of MSRT is cumulative, detecting current and past threats. MSRT detects over seventy five popular malware families (http://www.microsoft.com/security/malwareremove/families.mspx), which is far less than the 10,000 different malware programs that the normal antivirus software product can detect. MSRT is not intended to replace a user's other anti-malware programs. It is developed as an adjunct tool.

Microsoft only adds detection and removal capability to MSRT for a very small subset of all threats. In order for Microsoft to add detection and removal for a new malware family, the threat must be very common (or predicted to be very common soon), contain malicious instructions, and be actively running in memory when MSRT executes. This latter requirement also means MSRT will miss most data-based threats such as macro viruses and the other missed threats mentioned in the previous section.

MSRT can be run on computers running Windows 2000 or above. When MSRT (Mrtstub.exe) runs, it creates a randomly named temp directory in the root drive of the computer. Normally, the temp folder is automatically deleted after the tool is finished running although it can be manually deleted after the tool is finished if present.

The Malicious Software Removal Tool supports the following four command-line switches:

  • /Q quiet mode, suppresses end-user dialog boxes

  • /N forces detect-only mode

  • /F forces an extended scan

  • /F:Y forces extended scan and automatic cleaning of found infections

Results of the latest scan are stored in \%Windir%\Debug\Mrt.log along with a copy of the previous log (Mrt.old. When downloaded and run automatically, the most common method, MSRT runs in quiet mode by default. The tool notifies the first administrator to log on about the infection, detection, and removal that occurred, using a Windows balloon dialog box message.

By default, MSRT only runs a quick scan, checking only the most common autorun areas. In extended mode, MSRT scans the local hard drive(s) and detected removable media as well. An extended scan can take hours to complete. Figure 7-1 shows a manual MSRT in progress.

Image from book
Figure 7-1: A manual MSRT scan in progress

With millions of users running the tool, Microsoft also uses MSRT to judge the prevalence of a particular malware program. Microsoft is able to collect near real-time statistics that impact how quickly they respond to new threats.

For instance, during the early days of the WMF exploit (http://www.microsoft.com/technet/security/Bulletin/MS06-001.mspx) in January 2006, several security Web sites and media outlets published stories indicating that millions of computers were being infected by the WMF exploit. A high-risk outbreak would force Microsoft to develop and release a patch to the detriment of patch's quality.

Microsoft included WMF worm detection in MSRT and discovered only 16 infected computers out of millions of computers-an infection rate of 0.000016 in a million. Using facts, and not hyperbolic speculation, Microsoft slowed down the patch response time, and delivered a quality patch. Microsoft continues to use MSRT to assist in setting appropriate patch development response times.

New tool updates are kept as small as possible. When a user with a previous version of the tool installed is detected, only the delta updates are downloaded (when using Windows Update/Microsoft Update and Automatic Updates). Delta updates save approximately 1MB per user or download.

MSRT can be installed using normal software push mechanisms, and is fully scriptable. It can be rolled out using SMS and monitored and executed using WMI and other scripting interfaces.

If MSRT finds an infection, it removes the malware and reports the findings (see Figure 7-2). Unfortunately, MSRT does not tell you at what location the malware was detected. Hopefully, in future versions Microsoft will add more details.

Image from book
Figure 7-2: MSRT informs you when it finds and removes malware.

When malware is found, relevant computer and malware information is sent back to Microsoft (except on WSUS delivered versions). According to Microsoft, the information sent to it is only used to allow the Microsoft Anti-malware team to better serve its customers.


Security Center

The Security Center application was introduced in Windows XP Pro SP2, as a way of displaying a high-level overview of the system's security status in one screen window. After the install, Vista's first start highlights the Security Center summary screen. Administrators are asked to confirm and set configuration options.

The Security Center applet under the Control Panel (see Figure 7-3) allows a user to view or configure the following features:

  • Windows Firewall

  • Automatic Updates

  • Antivirus Program(s)

  • Windows Defender

  • Internet Explorer Security Options

  • User Access Control Status

  • Quick Link to Microsoft Security Web Site

Image from book
Figure 7-3: Windows Security Center allows a user to view or configure security features.

The Security Center gives a quick status update by displaying red (some-thing wrong, expired, or disabled), yellow (caution), or green (okay) status lights for each security category (see Figure 7-3). Third party software can customize the Security Center console. For example, in Figure 7-3, Trend Micro's PC-cillin antivirus program has modified the normal Windows Defender category to "Spyware and other malware protection" to reflect PC-cillin's installation and concurrent protection.

When enabled, Security Center monitors Windows current protection status and usually warns when security is being disabled or lessened by displaying balloon status messages. Unfortunately, monitoring seems to be hit or miss. Disabling the Windows Firewall almost always causes a warning message to be displayed, whereas disabling the Windows Defender never resulted in a warning message.

Note

The normal Security Center window is disabled when a computer is joined to a domain. The replacement Security Center applet does not display Antivirus or UAC status, and does not display the normal red, yellow, green quick status lights. The default Security Center window can be re-activated using Group Policy or Local Computer Policy by enabling Computer Configuration\ Administrative Templates\Windows Components\Security Center\Turn on Security Center (Domain PCs only).


Windows Defender

Windows Defender is Microsoft's real-time anti-spyware and unwanted pest detection and removal tool. Best of all, it's free. Windows Defender was originally created, and bought from, a company called Giant Company Software. It was completely rewritten and enhanced by Microsoft, and released as an extended beta download for Windows 2000 and above. Windows Defender is installed by default in Vista, and is available in 32-and 64-bit versions.

Windows Defender is installed as a service with an end user accessible front end. Unless configured otherwise, Windows Defender actively runs in memory, but doesn't make a noticeable appearance unless a potentially unwanted program is detected. End users can decide whether or not Windows Defender places an icon on the task bar, although users can always access it through the Control Panel or Security Center.

Windows Defender is integrated with an online community called SpyNet. If a user chooses to participate, their own personal choices when dealing with spyware and other unwanted programs are uploaded to SpyNet, and used to create a larger online reference database. The shared database is used by Microsoft to detect new forms of spyware, and to recommend treatment advice to existing users based upon the overall community's choices.

Both administrators and non-administrators can benefit from the Windows Defender's protection. Users do not have to be administrators to run software scans or to remove unwanted programs. It scans all downloads arriving via Internet Explorer version 6 and above, via Outlook, and is able to perform on-demand scans of local media (see Figure 7-4). Its real-time protection can prevent unwanted programs from being executed and installed anywhere within Vista (an example warning is shown in Figure 7-5).

Image from book
Figure 7-4: Windows Defender performing a scan
Image from book
Figure 7-5: A Windows Defender warning

Real-time protection can be set granularly. A user can choose whether to enable real-time scanning on the following areas:

  • Autostart Areas

  • System Configuration

  • Internet Explorer (add-ons, settings, downloads)

  • Services

  • Drivers

  • Application Execution (and registration)

  • Windows Add-ons

Windows Defender's software agents provide the real-time protection. They monitor, using the Msmpeng.exe or Msascui.exe processes, over a 100 computer locations, including autorun areas, startup folders, registry keys, and system settings. You identify the areas to be monitored by enabling or enabling the various real-time protection options, which you can see in the preceding list.

Windows Defender can automatically scan at a predetermined daily or weekly interval (see Figure 7-6). Quick scans can be initiated, checking only the most common areas for spyware and pest programs, or a full-scan can be done. Windows Defender checks for updated definitions just before scanning, and new spyware definitions are automatically downloaded using Automatic Updates.

Image from book
Figure 7-6: Windows Defender can be configured to run scheduled scans.

The user can be prompted to remove, ignore, or quarantine detected software, or, as shown in Figure 7-6, the user can configure Windows Defender to choose a default option automatically.

Windows Defender will look for spyware, adware, pest programs, and other programs reported by Microsoft and the Windows Defender SpyNet community. Windows Defender can even notify Administrators, in the event log, about changes made to a computer by previously allowed software (see Figure 7-7).

Image from book
Figure 7-7: Windows Defender can log to the event log when it detects changes.

Windows Defender also includes heuristic detection for previously unknown pest programs (Figure 7-8 shows the option setting). It can scan inside a few of the common archive file formats (for example, zip files). Best of all, Windows Defender can create a restore point before removing unwanted software, just in case its actions break a legitimate application or delete needed content. However, the current version of Windows Defender does not scan for browser cookies, which are often used by spyware and adware to track a user's online browsing activities.

Image from book
Figure 7-8: Windows Defender can perform heuristic scanning as well.

Windows Defender includes a Software Explorer feature (see Figure 7-9) that can reveal currently running programs, auto-starting programs, network connected programs, or currently installed Winsock Service Providers. As welcomed as this feature is, it doesn't come close to the detection accuracy and ease of use provided by the Autoruns tool (http://www.sysinternals.com/Utilities/Autoruns.html).

Image from book
Figure 7-9: Windows Defender gives information on startup programs.
Note

Sysinternals was bought by Microsoft in July 2006, so now Autoruns is a Microsoft tool.

However, the Software Explorer feature does provide a quick way to document the processes running under Svchost.exe. As discussed in Chapters 3 and 5, Svchost is a generic hosting process for many other Windows services. It is not unusual for multiple instances to be running. When troubleshooting malware or performance problems, it can be helpful to know what services are running under each instance of Svchost. The Windows Defender Software Explorer can reveal the details. In Windows Defender, choose Tools, Software Explorer. Then choose Currently Running Programs. Highlight the Microsoft Host Process for Windows Services (called Microsoft Generic Host Process in earlier versions), and it will reveal what programs (see Figure 7-10) are running under each instance of Svchost.exe.

Image from book
Figure 7-10: One of the best features of Windows Defender is that it gives you insight into the processes inside an Svchost.

Although Windows Defender is free, there is no centralized management console for deploying and managing in a large enterprise. Microsoft has made a custom administrative template file available so that Windows Defender can be managed using Active Directory group policy. In a future product called ForeFront, Microsoft will introduce manageability for Windows Defender-like functionality.

Windows Defender's accuracy has had its ups and downs. When it was first released, several publications ranked it in the top three anti-spyware programs in terms of accuracy. However, as of late 2006, Windows Defender is consistently ranked as having one of the poorest accuracy ratings by most anti-spyware reviewers. This is mostly due to the fact that Microsoft has intentionally made the decision for Windows Defender not to scan for, or to remove, unwanted browser cookies.

Spyware-and adware-based browser cookies are the most common type of unwanted content found by most anti-spyware tools. Microsoft chose not to detect or remove them because they are always low priority threats (that is, at most all they can do is track your Internet browser activities when visiting participating Web sites). Most anti-spyware programs choose to include, and remove them, because they spike their detection statistics. It is not unusual for hundreds to thousands of spyware-based cookies to be detected on a normal computer. If this single detection factor was removed from all the review rankings, Windows Defender would compare much more favorably to its competition.

Although the authors of this book wish that Windows Defender had the option to scan for unwanted browser cookies, and let the end users make the cookie detection decision, Windows Defender otherwise provides solid value to consumers. It will protect users from many critical threats. We encourage you to make individual decisions as to the desirability of this feature. This is yet another area where the security vendors (and the press) have attempted to spike statistics to show value that may or may not be there for a particular customer.

Windows Defender will be integrated tightly with Microsoft's Windows Live OneCare subscription service.


Windows Live OneCare

Windows Live OneCare (http://www.windowsonecare.com) is Microsoft's subscription-based PC protection service for non-enterprise computers. OneCare covers up to three PCs, giving antivirus, anti-spyware, host-based firewall, performance tune-ups, backups, and automated Windows patch management. About the only thing it is missing is e-mail anti-spam protection.

OneCare is composed of a front-end GUI connecting to several back-end services. The service list includes Msfwhlpr, Msfwdrv, Msfwsvc, Mpfilter, Msmpsvc, and Winss. It also relies on many default Windows services, such as Application Layer Gateway Service, Network Location Awareness, Plug and Play, Remote Procedure Call, Telephony, and Windows Management Instrumentation. Curiously, OneCare does not work with dynamic disks (see http://www.support.microsoft.com/kb/913964).

OneCare provides real-time and on demand antivirus scanning, with instant messaging support as well. OneCare has received several respected industry certifications, including West Coast Labs Checkmark (Trojan, Antivirus Level 1, Antivirus Level 2), ICSA Labs (Firewall and Antivirus), and the Virus Bulletin 100.

The firewall is a two-way Windows Firewall, but is not the same as the one built into Windows Vista. One very notable difference is in how it handles outbound blocking. The Windows Vista firewall provides a default set of outbound blocking rules that are actually meaningful and does not prompt the interactive user to allow/block outbound traffic for random programs as this provides no real security value (see Chapter 11 for a thorough discussion of the value of outbound rules). The OneCare firewall, unfortunately, takes the same approach as most third-party firewalls and asks the user to make decisions about outbound traffic based on information that is incomplete and meaningless to the vast majority of users. This also means that users must elevate to an administrator to allow or block a program each time a program is blocked, significantly increasing the number of User Account Control dialog boxes encountered.

To avoid incessant prompting when it is first installed, the OneCare firewall, comes in with many pre-installed firewall rule exceptions, not all of which are acceptable to all security defenders. For instance, (in at least early betas of the Windows Vista-compatible version), the OneCare firewall allowed any signed ActiveX control or Java applet to pass through the firewall. Unfortunately, malware writers have digitally signed content in the past, so some threats may slip by using this vector.

As mentioned previously, Windows Defender is integrated with One - Care. OneCare ensures the Windows Defender signatures are updated as needed. OneCare also e-mails participating users vulnerability threat warnings when the risk is high enough to warrant.

OneCare can perform backups to external hard drives or writeable discs (CD-RW, DVD+RW, and so on). When OneCare is first installed, it prompts the user to perform a backup. Thereafter, backups are automatically done before performance tune-ups.

Mid-size and large businesses with their own administrators and security officers probably want to avoid OneCare because when it is installed it provides no central management and it overrules previously installed software and configuration settings. For instance, it replaces previously customized Windows Firewall rules with OneCare's default rules. In most cases, OneCare's default rules are weaker than what the average security administrator would set. Overall, OneCare is an interesting, relatively inexpensive solution for home and small business users.


Microsoft Forefront Client Security

Microsoft's new, commercial Forefront Client Security (formerly known as Microsoft Client Protection) is designed to compete against the industry established players, such as McAfee, Symantec, and Trend Micro in the unified threat management arena. Forefront leverages several other Microsoft product technologies (for example, Windows Defender, OneCare, and so on), but can be distributed as a single client agent and managed using Active Directory. Microsoft SQL Server is used by Forefront as the event collection and reporting system. The agent can be deployed on Windows 2000 and above. The central management console allows centralized configuration and reporting.

Historically, Microsoft's previous forays into the antivirus industry have not been competitive or well received. However, this time Microsoft is taking a very strategic and dedicated approach to client security.


Should Microsoft Be in the Anti-Malware Business?

This is a good question to discuss. As critics rightly point out, the weaknesses in Microsoft's operating system have led to many, if not most, of the security problems that allow malware to be installed on end-user desktops. Why should the company causing the problem be allowed to offer, and sell, the solution to a problem they created?

This is a valid question, but the nature of a free-market economy is that anyone is "allowed" to be in any business they want. Whether customers will "trust" the offering they have is a different question altogether, and many of the established security vendors appear to be trying very hard to ensure that customers do not trust Microsoft's offerings, as noted previously. In essence, customers trusting Microsoft to succeed in security is harmful to the remaining security industry's business model, which has largely been based on protecting Microsoft's customers from Microsoft's mistakes. In Microsoft's defense, Microsoft has not intentionally ever allowed malware to be installed. Maybe in the past, Microsoft was more lackadaisical about security, but for at least half a decade they have been working tirelessly to prevent attacks.

A large majority of the malware that is installed on a user's system is so installed, intentionally or unintentionally, as a side-effect of some intentional act, by the user, usually when they fall for some social engineering method. And, if the end user installs untrusted software, it will always be successful, no matter what the operating system is. It's not like Linux, Unix, or Macintosh computers are anymore resistant to user-installed malware. It's just that they are attacked less because they are less popular. Other popular forms of malware, such as buffer overflows, haunt all popular desktop operating systems and will be successful most of the time despite the defenses put up by a software-based operating system. This is not to say that Microsoft could not have done a better job with security, but there are malicious methods that would be success against most operating systems regardless of the defenses.

Additionally, what harm is there in allowing Microsoft to offer up free or additional adjunct software protection alternatives? Rarely is the consumer hurt by being exposed to more choices. As long as Microsoft is not anticompetitive in pushing their computer defense choices over other vendors, additional choices are a good thing. If any of the Microsoft-derived tools prevent a malware program from being installed that might otherwise be missed, then they are a good thing.

For example, prior to Microsoft's Windows Firewall, many Windows users did not install a host-based firewall. There are many free choices, including the excellent and popular ZoneAlarm (http://www.zonealarm.com). But a large percentage of users never installed any host-based firewall, so those systems did not benefit by the additional protection. Microsoft, when it released, and later pushed, Windows Firewall, installed a host-based firewall to many XP users who would have otherwise never installed one. It is this large percentage of the desktop user population that benefits from Microsoft's additional security defense software products. And when those users are protected and less likely to be exploited, it benefits us all (because their systems aren't being used to spread malware and to attack our systems). If Microsoft's actions benefit its end users (without being anti-competitive) and prevent malware, it is a positive move for customers.


Summary

Microsoft's latest client security products offer better protection to Windows users. The Malicious Software Removal Tool scans and removes the most popular malware programs on a monthly basis. It has been responsible for removing malicious programs from millions of computers. The Security Center console allows a user to see the overall security status of Vista, including Windows Firewall, antivirus, Windows Defender, Automatic Updates, User Account Control, and Internet Explorer security options. Windows Defender is a competent anti-spyware tool providing real-time and on-demand protection. Windows Live OneCare is a new subscription-based service for protecting home and small business users. Microsoft Forefront Client Security provides a unified threat management agent that can be managed using Active Directory.

Chapter 8 will discuss the new features in Internet Explorer 7 and how to secure Internet browsers against malicious attack.


Best Practices

  • Install appropriate anti-malware defenses. Windows Vista does not come with all the defenses most people need.

  • Keep malware detection and removal programs up to date with the latest signatures.

  • If instructed by a vendor or troubleshooting technician to disable anti-malware software during a troubleshooting event, don't forget to reenable when the problem is fixed.

  • Always assume that your anti-malware software program(s) aren't perfect, because they aren't. In a given year, they will miss one or more malicious programs arriving in e-mail or through your web browser. Treat all unexpected, strange-looking e-mails as malicious until you can prove otherwise. Never click on an unexpected file attachment or web link, until you confirm that it is to be trusted.

  • Establish appropriate firewall practices.

Analyze the actual security features you need and critically evaluate all the products to see which provide them. Keep in mind that many of the "research reports" on security are written by people that have a product to sell (including Microsoft). Reporters are seldom immune from this product-oriented perspective either.


Part III: Securing Internet and E-mail Access

Chapter List

Chapter 8: Securing Internet Explorer
Chapter 9: Introducing IIS 7
Chapter 10: Protecting E-mail


Chapter 8: Securing Internet Explorer

Since its release, Internet Explorer (IE) has been Microsoft's weakest security point. As the most common browser in the world, it is a malicious hacker's most popular target. Nearly 85 percent of the world's computers run IE (see http://www.en.wikipedia.org/wiki/Usage_share_of_web_browsers). By exploiting IE vulnerabilities, hackers and criminals gain the largest possible foothold into the greatest number of potential victim machines.

Secunia (http://www.secunia.com/product/11) lists over a hundred Internet Explorer 6.x vulnerabilities, many remaining unpatched for a year or longer. Consequently, many Windows users are exploring browser alternatives. Fire-fox and other competing Internet browsers have gained notable market share over the last two years.

To decrease the risk of new malicious attacks utilizing IE and to restore consumer confidence, Microsoft created Internet Explorer 7.0. It contains dozens of security and feature improvements. IE 7.0 was pushed down as a critical upgrade for Windows XP Pro near the end of 2006, and is the installed browser of Windows Vista. Chapter 8 will cover the security features of IE 7 and discuss how to secure Internet browsing.

Should You Use Another Browser?

Many security "experts" recommend that IE be replaced by some other "more secure" Internet browser. Often they recommend Mozilla Firefox (http://www.mozilla.com/firefox), Safari (http://www.apple.com/macosx/features/safari), Opera (http://www.opera.com), or one of the other less known alternatives (Netscape, Lynx, Konqueror, and so on).

Note

Safari and Konqueror are not available natively for the Windows environment. However, both can be installed using emulation or interfacing software.

The belief is that because Internet Explorer is the most hacked software target in the world, switching to another browser will make any computer user more secure. And in the short run this statement might be true, albeit with a loss of key functionality.

But if everyone switched browsers to some other popular standard, the malicious hackers would just attack that product, and would probably be just as successful. Hackers hack popular software. They want the most bang for their effort. As a product becomes more popular, so too, does the number of attempts and announced exploits.

For example, Internet Information Server 6 (IIS 6) has a 19 percent worldwide market share in public web servers. Open source Apache (http://www.apache.org) has a 79 percent market share. IIS 6 has had three exploits (http://www.secunia.com/product/1438) since its release in March 2003. Apache 2.x has had over 30 vulnerabilities (http://www.secunia.com/product/73) in the same time period. We can either say that Microsoft IIS 6 is significantly more secure than open source Apache, and that may be likely, or that Apache's wider popularity and availability attracts more hackers. Either way, market share attracts hackers. Similar statistics occur on nearly every product type and platform, with few exceptions.

When Mozilla's Firefox 1.0 (http://www.mozilla.com/firefox) came out in November 2004, it was heralded as the world's best and most secure browser. And a lot of the world bought the hype and switched from IE. Since late 2004, Firefox has garnered anywhere from 8 to 15 percent of the Internet browser market, depending on whose survey you believe.

Firefox is a great, open source browser. But more secure? According to Secunia (http://www.secunia.com/product/4227), Firefox 1.x has had over 35 announced vulnerabilities discovered since its release. Since June 2006, the time period when IE 7 announced its first public security advisory, Firefox 2.x has had 6 advisories to IE 7.x's 9 (as of April 2007). Do you think Firefox will become more or less hacked as it becomes more popular? Browser vulnerability statistics ebb and flow with each month's discovery announcements, but can an Internet browser with nearly as many security advisories as IE be considered the secure alternative?

Other browsers look like less promising security alternatives if their market share is compared to the number of found vulnerabilities (see Table 8-1).

Table 8-1: Comparing Browser Market Share to The Number of Vulnerabilities Open table as spreadsheet
BROWSER | IE 7.x | Firefox 2.x | Safari 2.x | Opera 8.x
Percent market share | 85% | 11% | 2% | 1%
Number of vulnerabilities from June 2006 to April 2007 | 9 | 6 | 3 | 5
Market share statistics provided by http://www.en.wikipedia.org/wiki/Usage_share_of_web_browsers. Vulnerability statistics provided by http://www.secunia.com.

No single set of numbers measuring only one vulnerability facet can begin to summarize one browser's security over another. The main takeaway idea from Table 8-1 is that all browsers have holes and exploits, which increase with popularity. This makes sense as more people and hackers use and test the software.

Switching from one browser to another may provide a temporary measure of security, but if the world decides to make a new browser the more popular, the security through obscurity benefit begins to fade. In a large organization, switching all the users from one browser to another may provide a temporary benefit. But after all the hard work and re-education, the security risks may end up the same.

The real answer is that all popular browsers can be used securely to minimize the risk of malicious exploitation. IE 7, in particular, has a very robust, granular, security model. It defeats all the past attacks and raises the bar for future attacks.

But remember that ultimately there is no such thing as a completely secure Internet browser. If you choose to install an Internet browser and connect to the Internet, you have increased the risk of malicious exploitation-regardless of the browser.

High security networks, such as the United States Armed Services classified networks, don't allow their computers to connect to the Internet. If you want to eliminate the risk of an Internet browser attack, don't install an Internet browser or don't allow connectivity to the Internet. But if you simply want to minimize risk as you and your end users browse the Internet, then the rest of this chapter is for you.

Image from book
INTERNET EXPLORER NO LONGER REQUIRED IN VISTA

In previous versions of Microsoft Windows, IE was tightly integrated with Windows. Even if you installed an alternative browser, IE was often used as the browser of choice by many applications and applets. IE's functionality and components were a central part of Windows that you could not disable. Pragmatically, this meant that even if you used another browser, you still had to keep IE up to date patched and secure. And if you have to do that anyway, why run another browser?

Per Microsoft, starting with Windows Vista, IE is truly an optional component. This is good for the anti-IE crowd (and I think a correct choice for Microsoft). Still, most of the world's Web sites and applications expect IE to be the client browser. If you choose another browser besides IE, you could run into compatibility problems. But at least now users have a true choice.

Image from book


New IE 7.0 Security Features

IE 7 has dozens of new security features. This section will not cover the dozens of other new features that have nothing to do with security (for example, tabbed browsing, RSS support, improved printing, search block, and so on). Here are the most significant security improvements:

  • Protected mode

  • Anti-phishing filter

  • Improved add-on management

  • Improved ActiveX control handling

  • Improved digital certificate handling

  • Improved encryption support

  • Improved URL handling protections

  • CardSpace

  • Parental controls

  • Privacy improvements

  • Pop-up blocking

  • Improved Cross Domain Scripting protections

  • Support for International Domain Names (used in a Firefox exploit in 2005)

  • RSS feeds automatically run in the Restricted sites zone

  • Larger minimum window sizes so that even at the smallest size, enough of the address bar and status bar are displayed to allow users to make trust decisions

  • Over a dozen new security options (covered in the material that follows)

  • Security status bar (easier and quick identification of Internet problems)

  • One-click Fix My Settings feature

  • Single-click browser content cache deletion

All of these improvements add up to a better and more secure Internet browsing experience. The next few sections cover the improvements with the biggest security impact.

Protected Mode

As covered in Chapter 1, one of the most significant improvements to Vista is Internet Explorer's new Protected Mode. All security principals (for example, users, computers, groups, services, and so on) and objects (for example, files, printers, registry keys, and so on) are given a mandatory integrity ranking. The value can indicate low, medium, high, or system integrity.

All programs and applications run in the security context of a security principal (called impersonation or delegation, covered in Chapter 3). Most Windows system files (and most default Services) run in the Local System context. Most normal applications run in User mode, which means the application runs in the security context of the user who started it.

In Vista, when an application (with a given user's security context) attempts to access an object, both integrity levels are checked. If the program's security principal's integrity rating is equal to or greater than the object's integrity value, then it is possible for the security principal to write, modify, or delete the object, if the subsequent NTFS security permissions also allow it. If the security principal's integrity level is lower, the security principal will not be able to write, modify, or delete the object they are attempting to access regardless of the NTFS permissions. Integrity SIDs have precedence over NTFS permissions.

System objects are given the highest integrity rating of system. Most users and applications are given medium integrity by default. All normal Windows files and the desktop have medium integrity, but Internet Explorer running in Protected Mode runs with low integrity.

The idea is that even if a malicious program is able to "break out" into a system, if it originates from a low or medium integrity process, it will have a harder time modifying Windows system files than it would in previous versions of Windows. If malware successfully exploits Internet Explorer and then attempts to leverage that exploit into a further compromise of the system, as is common, the new integrity controls will make it much more difficult to accomplish.

For example, if Internet Explorer 7 is buffer overflowed, the malicious code will usually then attempt to install or modify files in the \System32 folder or startup areas (for example, HKLM\Software\Microsoft\Windows\CurrentVersion\Run registry key). Usually the hacker is attempting to install a backdoor program or to insert a malicious command and control program. Vista can prevent the subsequent modification, so that even though the initial exploit was successful, the overall outcome prevents the hacker from taking eventual control. To the hacker, it appears as if the exploit did not work at all.

Note

Although Windows XP Pro can run IE 7, it cannot run it in Protected Mode.

By default, IE runs in Protected Mode for most Web sites, and any process, child process, add-on, menu bar, and so on, related to it runs in low integrity. This is true even if the Administrator or an administrator-equivalent started IE. IE or any related process can only access low integrity locations by default without additional administrative confirmation.

New Low Integrity Folders and Registry Keys

Microsoft has created new "Low versions" of popular folder and registry keys. By default, low integrity locations intended for use by IE and its processes include:

  • \Users\%Userprofile%\AppData\Local\Temp\Low folder

  • \Users\%Userprofile%\AppData\Local\Temp\Low\Low folder

  • \Users\%Userprofile%\AppData\LocalLow folder

  • \Users\%Userprofile%\Local Settings\Temporary Internet Files\Low folder

  • \Users\%Userprofile%\Local Settings\Temp\Low folder

  • \Users\%Userprofile%\Local Settings\Temp\Low\Low folder

  • \Users\%Userprofile%\Local Settings\History\Low folder

  • \User\%\Userprofile%\Local\Temp\Low folder

  • \Users\%Userprofile%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low folder

  • \Users\%Userprofile%\AppData\Local\Microsoft\Windows\History\Low folder

  • *\Users\%Userprofile%\AppData\Roaming\Microsoft\Windows\Cookies\Low folder

  • HKLM\Software\Microsoft\Internet Explorer\Low Rights registry hive

  • HKCU\Software\Microsoft\Internet Explorer\LowRegistry registry hive

Essentially, a low integrity program can write to any low integrity area or object in Windows (if NTFS permissions also allow it), plus IE can write to any file or content it creates in those low integrity areas.

Note

The Low integrity folders vary system to system, and there are certainly going to be more Low integrity folders than are listed previously. Additionally, newly added applications can add their own application-specific folders.

Internet Explorer 7 is in Protected Mode by default for all security zones except the Trusted Sites zone. IE 7 displays whether or not it is in Protected Mode on the status bar (see Figure 8-1). Protected Mode can be turned off in the Internet Explorer Internet Options dialog box for each zone (see Figure 8-2), or using group policy.

Image from book
Figure 8-1: Internet Explorer's Protected Mode can be enabled or disabled on a per zone basis.
Image from book
Figure 8-2: Internet Explorer's status bar indicating that Protected Mode is enabled

In previous versions of IE, if the logged-in user was an Administrator (which was often the case), malware exploiting Windows could exploit the user's system. IE Protected Mode complicates the job of viruses, worms, Trojans, adware, and spyware when they're trying to hijack the user's computer.

IE Compatibility Shims

Of course, users and developers need a way to install legitimate programs and content. Microsoft allows this using a new shim compatibility architecture. By default, a program or process spawning from IE can access only low integrity resources. If they try to access objects with higher integrity, they will be denied.

However, if a program or process attempts to write to a medium integrity object, such as the HKCU\Software registry hive or the user's My Documents folder, Windows will redirect registry writes to:

     HKCU\Software\Microsoft\InternetExplorer\   Image from book
     InternetRegistry\REGISTRY\USER\{user's SID}\Software

and the file writes to

     User\%UserProfile%\AppData\Local\Microsoft\Windows\   Image from book
     TemporaryInternetFiles\Virtualized\{system drive   Image from book
     letter}\Users\{username)

Programs, legitimate or not, can request access to higher privileged objects using two new broker processes:

  • Ieinstal.exe (Admin Broker)

  • Ieuser.exe (User Broker)

Ieuser.exe runs with medium integrity and Ieinstal.exe runs with high integrity. Processes running under either broker are subject to normal registry and file virtualization rules, and will be further protected by Data Execution Prevention (DEP). When a user intentionally downloads a file, Ieuser.exe will participate in the downloading of the file. The downloaded file and the process will be marked with medium integrity. Manually initiated install processes will run with high integrity.

IE will either automatically call these additional, elevated broker processes when needed, and Microsoft allows developers to access higher levels of integrity through a variety of programmatic means. Most require that the installing user approve the action. Figure 8-3 shows an example dialog box.

Image from book
Figure 8-3: Program prompting the user to run it outside of Protected Mode
Note

Interestingly, although Ieuser.exe and Ieinstall.exe are protected by DEP, 32-bit versions of Iexplore.exe are not (64-bit versions are protected by DEP), making IE still susceptible to many common buffer overflow types.
Note

It important to realize that files manually downloaded or installation/setup routines initiated by a user will use the elevated processes of Ieuser.exe or Ieinstal.exe. Bypassing IE's Protected Mode is as simple as convincing the user to download or run a file. IE's Protected Mode is designed to make downloads and installs without the user's consent (i.e. "drive-by-downloads") harder to pull off for the malware writer.

Protected Mode's Impact on Malware and Hackers

It is interesting to note that Microsoft has documented how developers can use compatibility shims and brokers to elevate integrity levels of their programs or communications. Microsoft even possibly allows a newly installed program to modify the registry in such a way that the program can elevate itself to a medium integrity or communicate to a medium integrity process without warning the user (see http://www.msdn.microsoft.com/ie/default.aspx?pull=/library/enus/IETechCol/dnwebgen/ProtectedMode.asp). So, just like before, in previous versions of Windows, the user's decision to run or install any program can allow the program to do more than the user originally intended.

Note

Although there is documentation discussing how an application can "silently elevate" itself, the functionality does not appear to work. The authors hope that the feature documented previously is never implemented.

The impact of Protected Mode on IE's overall security is yet to be tested thoroughly. Three major issues loom. First, as covered above, 32-bit versions of Iexplorer.exe (i.e. the main Internet Explorer) executable does not run with DEP protection, which means IE is still susceptible to many common types of buffer overflows. Microsoft was forced to initially exclude 32-bit versions of IE from DEP protection because many popular IE legacy add-ons, including Adobe, Flash, Active Type Library, and Sun's Java Virtual Machine (JVM), will cause fatal error problems. When operational problems occur, regardless of the reasons, many end users will blame Microsoft and not the add-on vendor. They will not be understanding of Microsoft's need to develop a more secure browser, so Microsoft has to ensure a moderate level of backward compatibility.

Second, if the user can be tricked into downloading a file or running a malicious executable, that file will be downloaded or executed with elevated integrity, bypassing one of the strongest IE-PM protections.

Third, it's excellent that Microsoft block writes to critical system areas. However, it is likely that new threats will be able to accomplish historical types of maliciousness by using only the low integrity areas.

Luckily, in many instances, Vista's separation of privileges will prevent one user's mistake from infecting the whole system. But if malware is able to leverage a user's low integrity areas, they can at least maliciously interact with that user. If the computer is only used by a single user it doesn't really matter whether the malware attacked only one user's profile or the whole system. However, if malware is prevented from manipulating trusted system areas, it is a huge advantage and means detection and removal tools can be more accurate. Whether malware can break out of Protected Mode and infect the whole system is a tougher problem for malware writers to solve. Unfortunately, if past history is any guide, worm and Trojan creators will eventually figure out a way to circumvent IE's Protected Mode. Although IE 7-PM is significantly previously secure than previous versions, it is likely that the weaknesses mentioned above, and other newly discovered vulnerabilities, will mean that IE 7 remains a frequent hacker target of success.

Anti-Phishing Filter

E-mail phishing attacks have become a huge security problem. A phishing attack involves ending a realistic, but fraudulent e-mail to an unsuspecting end user asking for confidential information (usually logon information, passwords, or financial information). Over the years, phishing e-mails have become so legitimate looking that they are hard for the novice to identify. See http://www.antiphishing.org for more phishing details.

IE 7 has new intelligence to scan all incoming Web content looking heuristically for signs that might indicate a malicious phishing Web site. By default, IE will check with Microsoft on every incoming Web site URL in all zones except the Trusted Sites to see if it has been previously reported as a malicious Web site. If it identifies a previously reported and confirmed phishing Web site, it will declare the Web site as a known phishing site and block the access (see Figure 8-4). If the Web site has not been reported, but still appears suspicious, IE 7 displays a gold warning bar (see Figure 8-5).

Image from book
Figure 8-4: Internet Explorer's phishing filter detecting a known phishing Web site
Image from book
Figure 8-5: Internet Explorer's phishing filter warning about a possible phishing Web site

While IE 7's anti-phishing filter isn't extremely accurate (it suffers from a fair amount of false-positives and false-negatives), it is a nice added feature to the IE family. Users can report any Web site to Microsoft as potentially malicious (see Figure 8-6), and Microsoft will verify the site's intent before adding it to their database as malicious. Users have to type in the correct, obscured letters (see Figure 8-7) to successfully report a suspected phishing Web site. This is to prevent Phishers from submitting thousands of legitimate sites programmatically to decrease the accuracy of Microsoft's databases.

Image from book
Figure 8-6: Microsoft's phishing filter online reporting form
Image from book
Figure 8-7: Microsoft's phishing filter online reporting form challenge

Add-on Management

Insecure Add-ons (i.e., Browser Helper Objects and extensions) have been responsible for many of the IE security vulnerabilities. To that end, Microsoft has made it much harder for any Add-on to modify Internet Explorer without a user's permission (for example, UAC, Protected Mode), and a user can more easily manage and disable current Add-ons.

Add-on management is accessed through the Tools, Manage Add-ons, Enable or Disable Add-ons IE menu choices. By default, the Add-ons currently loaded in IE will be displayed (see Figure 8-8), both the enabled and disabled programs. You can also use the new Manage Add-on option box to show all previously loaded Add-ons. It can also show Add-ons requiring permissions to run, and all the previously downloaded and installed ActiveX controls.

Image from book
Figure 8-8: Internet Explorer's Manage Add-ons feature

You can run Internet Explorer without any active add-ons by clicking the Start button, and then choosing All Programs, Accessories, System Tools, and then clicking on Internet Explorer (No Add-ons). You can run IE7 in Windows XP without add-ons by right-clicking Internet Explorer's icon or executable and selecting Start without Add-ons.

When IE 7 starts it checks the list of installed Add-ons. Previously identified Add-ons that cause stability or security problems will be prevented from loading by default. The user will be prompted to enable, disable, or check for updated versions (see Figure 8-9).

Image from book
Figure 8-9: Internet Explorer detecting an installed incompatible Add-on application during startup

Improved ActiveX Control Handling

Insecure ActiveX controls have been responsible for many buffer overflows and privilege escalation attacks. IE 7 disables all ActiveX controls that were not previously used in IE 6. When a user runs an ActiveX control for the first time on the Internet or in Restricted sites zones, they will see a warning bar asking to approve the control. The ActiveX Opt-in policy does not apply to the Intranet and Trusted Sites zones, or to any controls previously approved by the Administrator or through group policy.

Improved Digital Certificate Handling and Encryption

A HTTPS protected web page ensures that the Web site is authenticated (that is, it is who it says it is) and that all communications between the server and the client are encrypted. HTTPS is an Internet standard and supported by most browsers and commercial Web sites.

HTTPS and digital certificates work well if the users pay attention to the errors and warning messages from invalid sites and certificates, which is not usually the case. IE 7 is more "in your face" with site and certificate errors. If an HTTPS Web site has a digital certificate error, IE 7 warns the user, gives exact details for the warning, and refuses to display the page by default (see Figure 8-10). The user can click the warning message for more details, close the page attempt, or continue on. Additionally, elevation is needed to permanently install any remote Web site's digital certificate.

Image from book
Figure 8-10: Internet Explorer detecting a Web site's invalid digital certificate

IE 7 is doing its part to engage users to pay attention and to increase the security of HTTPS at the same time. First, weaker SSL ciphers (40-bit and 56-bit) have been disabled by default. Vista now supports 128-bit and 256-bit SSL encryption routines. The older and weaker SSLv2 protocol has been disabled by default. SSLv3 and the even stronger TLS routines have been enabled by default.

Digital certificate revocation is enabled by default. Certificate revocation occurs when an issuing Certification Authority or the digital certificate it issued becomes compromised. If a digital certificate is revoked, it should be considered untrustworthy. In IE 6, certificate revocation was optional, but improved support for the OCSP protocol allows Microsoft to have confidence when turning it on. Last, HTTP content attempting to post inside a HTTPS page (called mixed content) is blocked by default. IE 6 just warned. Some Web sites use mixed content, but doing so is normally considered a security vulnerability.

By disabling weaker ciphers, enabling better encryption protocols, and blocking sites with certificate problems, essentially Microsoft is telling Web site developers to get up to date on their security. Only time will tell whether or not HTTPS and digital certificates will truly lead to better, improved security.

Improved URL Handling Protections

IE 7 will no longer render URLs that do not meet RFC guidelines. Many phishing and spam e-mails, and hacker attacks, use malformed and encoded URLs to initiate their maliciousness. IE 7 has been specifically coded to ignore and drop suspiciously encoded URLs and other devious strings. (For example, %25 in URL paths will no longer be decoded to %, stopping many obscurity and directory traversal attacks.) The common directory traversal string ../../../../../ doesn't work anymore. Improved URL handling protects end users and also vulnerable Web sites.

CardSpace

Windows CardSpace is Microsoft's new method for delivering logon credentials and other information (for example, credit card numbers, personal identity information) to participating Web sites and network resources. Users create individual "cards" (see Figure 8-11), which can then be securely transmitted to requesting sites. It is a user-centric, user-managed identity management space. When creating and transmitting cards, CardSpace becomes the focus while the UAC mechanism prevents malicious interactions on the local computer. Many people believe that CardSpace is a replacement for Microsoft's Passport mechanism. CardSpace will probably replace Passport, but operates differently and can do much more. There is a great wiki discussion on CardSpace located at http://www.en.wikipedia.org/wiki/Windows_CardSpace.

Image from book
Figure 8-11: Example CardSpace entries
Note

CardSpace is also available in Windows XP if .NET Framework 2.0 or later is installed.

The previous sections explored the biggest changes between IE 7 and IE 6. The next section will cover IE security zones and security zone settings.


Internet Explorer Security Settings

IE has very granular security settings that outpace any of its rivals. You can place Web sites in one of five IE security zones, and modify nearly 50 settings for each zone.

Security Zones

Internet Explorer has five different security zones:

  • Internet

  • Local intranet

  • Trusted sites

  • Restricted sites

  • Local computer

Internet security zones allow users to granularly define specific permissions for different Internet or intranet resources. Internet Explorer allows users (or administrators) to define ahead of time particular security permissions and privileges for various Web sites.

Local Computer Zone

The first four zones are readily accessible in IE (see Figure 8-12) by choosing the Tools menu option, then Internet Options, and then clicking on the Security tab. This unlisted zone is not easily end-user definable and represents content residing on the local computer. Also known as the My Computer zone, Windows now warns the user if content in the Local Computer zone wants to execute in IE. In earlier versions of IE, content from the Local Computer zone ran in the security context of the active user, but in IE 6 on XP SP2 and later versions, it is locked down with additional restrictions to prevent malware execution.

Image from book
Figure 8-12: Internet Explorer security zones

The Local Computer zone lock down establishes the following default behaviors:

  • ActiveX controls may not run.

  • Java applets may not run.

  • Users may be prompted before they can run a script.

  • Users may be prompted before they can open a data source belonging to a different domain than the original server.

The Local Computer zone cannot be manipulated in IE by the end user, but can be configured using registry edits and programmatically. The zones can be manipulated in the registry at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones. Each Zone is represented by the number 0 to 4, going from least to most restrictive. 0 is the My Computer zone, 1 is the Intranet sites zone, 2 is the Trusted Sites zone, 3 is the Internet zone, and 4 is the Restricted sites zone. If you are interested in manipulating zones using the registry read Microsoft KB article #182569 (http://www.support.microsoft.com/?id=182569). Editing zones via the registry allows a higher level of granularity than you can obtain through IE (that is, defining of acceptable TCP/IP port numbers and protocols for each zone), but for most users IE zones settings are best configured in IE.

Internet Site Zone

The Internet site is the default zone for all content not previously defined as residing in one of the other zones. Most of the time when you are surfing on the Internet using IE, the content being downloaded will reside in the Internet zone. The permissions and privileges in the Internet zone are moderately restricted (with a default of Medium-High security) as compared to the other zones. The security level is appropriate for most Internet sites, but is too lax when unpatched vulnerabilities are encountered or overall risk is high.

The Internet zone allows all scripts, signed ActiveX controls and Add-ons to run, although unsigned controls and plug-ins are disabled by default. Many Internet attacks can be stymied if scripting and ActiveX controls are disabled, but doing so will cause problems with many legitimate Web sites. If a widespread vulnerability is present, users can benefit greatly by customizing the security (covered next) to disable scripting and other non-HTML content. Most users could benefit by customizing the Internet security zone to an acceptable level of usability and security.

Local Intranet Zone

The Local intranet zone is a zone with elevated default privileges. The default security level is Medium-low. The intent is that users (or administrators) place internal trusted Web sites in the Local intranet zone, and any sites in this zone will have elevated privileges. By default, all Web sites residing on the local LAN (and other defined private IP subnets) will be placed in the Local intranet zone without the user having to specifically add the Web site. External Web sites can be added as well (see Figure 8-13), although users should remember that sites in this zone have elevated privileges.

Image from book
Figure 8-13: Adding a Web site to the Local intranet zone

As Figure 8-13 shows, along with the default selections, there are several options under the Local intranet zone. The first is "Include all local (intranet) sites not listed in other zones." This means that any server sites on the local network not listed in the Trusted Sites or Restricted sites zone will automatically be included here. If you disable this option, sites on the local network will not automatically be included in the Local intranet zone.

The "Include all sites that bypass the proxy server" option assumes that IE uses a non-transparent proxy to access non-local sites. By enabling the option, IE will add any sites to the Local intranet zone that are excluded from having to be filtered through the proxy server. The thinking is that only trusted sites would be excluded from being handled by the proxy server, and because they are trusted, they should be included by default in the Local intranet zone.

The Include all network paths (UNCs) option instructs Windows to include any NetBIOS shares in the Local intranet zone. This setting means that any security choices made on the Local intranet zone might impact regular Windows drive mappings. The Advanced button allows sites to be added manually. By default, the sites added to this location must be protected by using the HTTPS protocol to ensure site location authenticity, but this option is often deselected.

Note

The Local intranet zone is disabled by default for non-domain computers.

Trusted Sites Zone

Sites placed in the Trusted Sites zone have minimal restrictions and a Medium security level, but are not protected by Vista's Protected Mode. Most actions and content will be allowed to execute without user intervention. Even the highest risk actions only require the user to acknowledge before they proceed. Unlike the Local intranet zone, the Trusted Sites zone does not include Web sites by default. New sites can be required to be protected by HTTPS, the default, or just unsecured HTTP.

Note

The Trusted Sites zone's default security level in IE 6 was Low.

Restricted Sites Zone

The Restricted sites zone, as its name implies, restricts most non-HMTL content and activity by default. The security level is High. The only activity allowed without user intervention is pop-up ad blocking and font downloading. By default, no sites are within this zone. The Restricted sites zone has no HTTPS requirement option.

Most users won't have any entries here because if the Web site is high risk, they should not go there. With that said, if a user plans on visiting a high-risk Web site, they should put the Web site's domain name here, although don't expect IE's High security level setting to prevent all attacks. Malicious Web sites often have unknown "zero-day" attacks or use social engineering methods to trick the user into executing malicious code.

You can also create your own IE security zones programmatically or using registry edits, however, these zones are not easy to configure and cannot be accessed using the IE GUI. For more information, see http://www.blogs.msdn.com/ie/archive/2005/01/26/361228.aspx. I hope that Microsoft creates an easy way for an unlimited number of new zones to be easily created and configured in the future. Why they have not done this already is a mystery. Next, this chapter will cover in detail each IE security setting and their default settings in each of default zones.

Zone Security Settings

IE 7 has over 45 separate security settings that can be customized for each IE security zone. Each one is summarized here along with general recommendations. Recommendations differing from Microsoft's default settings will be noted where applicable.

.NET Framework-Loose XAML

XAML files are markup files that use Extensible Application Markup Language (XAML), which is the user interface markup language for .NET 3.0's Windows Presentation Foundation (WPF) platform. See http://www.en.wikipedia.org/wiki/XAML for more details. Loose XAML is a new .NET capability that allows a user to launch any XAML file on their hard disk (or a URL link on a web page) and run it within a browser without compilation. Loose XAML is a markup language and can only render existing content, making it a low security risk. It is enabled for all zones except for Restricted sites.

.NET Framework-XAML Browser Applications

This security setting covers, for lack of a better description, non-loose XAML, which is compiled and must be run within the confines of a browser. As with Loose XAML, it is low risk, and enabled by default in all zones except for Restricted sites.

.NET Framework-XPS Documents

The XML Paper Specification (XPS) is Microsoft's newest document format. Royalty-free, XPS uses WPF to render a document on the screen the same as when it is printed. Many see XPS as competitor to Adobe's PDF format. XPS doesn't appear to have the sophistication of PDF, and as such, probably isn't much of a security risk. Microsoft has enabled it in all security zones except for Restricted sites.

.NET Framework-Reliant Components-Run Components Not Signed with Authenticode

The .NET Framework is Microsoft's client-server programming environment (with some loose comparison to Java's virtual machine environment). .NET is the dominant form of programming across the Windows platform.

Code is signed to prove authorship. Authenticode is Microsoft's digital signing mechanism for authenticating code, scripts, and ActiveX controls. Any software publisher (vendor) can purchase an Authenticode digital certificate for code signing.

Running an unsigned component means that you cannot automatically authenticate who created and initially distributed the component (and whether or not it is untrusted). Microsoft allows unsigned components to run automatically in all zones but the Restricted zone. I believe Microsoft was too lax on this setting. It should be set to disabled in Internet and Restricted sites zone.

Note

This option and the next may not be available unless you have also installed the .NET Framework client software.

.NET Framework-Reliant Components-Run Components Signed with Authenticode

Signed code is rarely a problem. Signed code can contain bugs and viruses (we hope that these would be unknown to the signer at the time the code was signed), but it is not common. If you trust the signed code to be non-malicious, you can accept it to run automatically. There have been instances where spyware and adware companies used signed code to distribute their largely unwanted software. Microsoft enables this in all zones, but the Restricted zone. Because of the spyware and adware issues, we suggest this setting be set to Prompt in the Internet zone.

ActiveX Controls and Plug-Ins-Allow Previously Unused ActiveX Controls to Run Without Prompting

This setting instructs IE to allow previously installed ActiveX controls that have never been run before to execute without warning the user. Hackers often take advantage of rarely used, but installed controls. Microsoft has rightly disabled this setting in the Internet and Restricted sites zones.

ActiveX Controls and Plug-Ins-Allow Scriptlets

Scriptlets refers to Dynamic HTML (DHTML) scriptlets, which were deprecated in IE 5. In the past, there were a few malicious exploits that used DHTML scriptlets. For that reason, Microsoft has correctly disabled them in all security zones except the Local intranet zone.

ActiveX Controls and Plug-Ins-Automatic Prompting for ActiveX Controls

ActiveX controls can be virtually any content, executable, or script delivered over a network through IE. Java applets are even delivered as ActiveX controls, in most cases. Windows uses dozens to hundreds of ActiveX controls. Most aren't needed in IE and one of the big changes in IE 7 is to not allow any ActiveX control to run in IE by default, except those expressly authorized by the user or admin. This is the opposite behavior for IE 6.x and before.

This particular setting determines whether or not the user will be prompted by a pop-up dialog box to install an ActiveX control or plug-in. If disabled, the Web site will attempt to download and execute the content, but IE will not prompt the user with a dialog box. Instead (if IE 6.x XP SP2 or higher is installed) the user will be warned on the yellow information bar about an ActiveX control needing to be installed. The information bar warning is less obvious than a pop-up dialog box in the middle of the browser window.

Microsoft enables this option in the Local intranet zone and disables it in the rest. How this setting is configured to is up to the user, although I always like to be prompted in an obvious manner for any ActiveX controls that are trying to be installed. Otherwise, a Web site feature may fail and the cause of the failure might not be readily apparent.

ActiveX Controls and Plug-Ins-Binary and Script Behaviors

Binary behaviors (http://www.msdn.microsoft.com/workshop/browser/behaviors/howto/creating.asp) were introduced in IE 5.5 and allow binary programs to be linked to and control HTML content. A binary behavior is a compiled object that can interact directly with the underlying OS. Its code cannot be read or examined using normal view source commands. They can be used to do many malicious things from a web page.

Prior to Windows XP SP2 and Windows Server 2003 SP1 (where this setting first arrived), there was no way to prevent a binary behavior in any IE security zone, including sites residing in the Restricted sites zone. Now, by default, binary behaviors are disabled in the Restricted sites zone, but allowed in the rest. We believe that binary behaviors are too powerful to be allowed from any Internet site. Accordingly, this option should be set to Disabled (or Administrator approved) for all zones, unless needed.

ActiveX Controls and Plug-Ins-Display Video and Animation on a Web Page That Does Not Use External Media Player

If enabled, this setting could allow an untrusted media player to execute active content within a Web site. Microsoft has correctly disabled this setting for all security zones.

ActiveX Controls and Plug-Ins-Download Signed ActiveX Controls

Signed ActiveX controls usually present little risk unless signed by a spyware or adware vendor. IE prompts the user to approve on zones except for the Restricted sites. These defaults are acceptable.

ActiveX Controls and Plug-Ins-Download Unsigned ActiveX Controls

Unsigned ActiveX controls are highly risky and, generally, should be disabled, or set up to prompt if you plan to come in contact with needed unsigned controls. Microsoft correctly disables them in all zones.

ActiveX Controls and Plug-Ins-Initialize and Script ActiveX Controls Not Marked as Safe for Scripting

Once ActiveX controls or plug-ins (plug-ins are usually ActiveX controls) are downloaded-which is the option being decided in the two options mentioned previously-there is still the matter of whether to execute them. Vendors can mark their ActiveX controls as Safe for Initialization and Safe for Scripting. The first option determines whether the control can be initialized (i.e., started and executed). The second option is whether it can be directed by scripting, which means it could have different outcomes based upon the script. If both options are selected, then any web page can invoke them.

The idea is that if the vendor determines the control is safe (that is, can't be used in a harmful way), then why not let other web pages and programmers re-use the control? Unfortunately, there is no official guidance or testing tool that a vendor can run to find out if their "safe" control is really safe. In more than a dozen different exploits over the years, a control marked safe for scripting, was used to do something malicious.

In this particular option, IE is asking whether or not to allow web pages to initialize and script controls that are not marked safe? Considering that controls marked safe for scripting are potentially dangerous, ones that were tested and not found to be safe by their vendors definitely should not be allowed to run. Microsoft disables them in all zones. The default settings are good.

ActiveX Controls and Plug-Ins-Run ActiveX Controls and Plug-Ins

This setting has a huge impact on IE. It determines whether IE can run ActiveX controls and plug-ins at all, regardless of their safety, and regardless of whether they are signed or unsigned. Disabling this feature defeats many, if not most, exploits that have attacked IE over the years. Unfortunately, it is such an all-or-nothing proposition that disabling it causes problems with many popular Web sites.

Microsoft enables this option by default in all zones, but the Restricted sites zone, where it is disabled. This is an acceptable default. However, if you are worried about a widespread, malicious IE vulnerability that cannot be stopped by disabling this option, consider disabling this option until a patch or other alternative defense can be applied.

Alternately, IE can be instructed only to allow administrator-approved controls to run. In order to use this option, you must use group policy, an administrative template, a security template, or the IE Administrator's Kit-and know the control's CLSID.

ActiveX Controls and Plug-Ins-Script ActiveX Controls Marked Safe for Scripting

This setting discusses whether controls previously marked "safe" can be scripted. This is one of the toughest calls because ActiveX controls that were thought to be safe for scripting have been involved in many vulnerabilities over the years, but disabling it causes problems with many legitimate Web sites. Microsoft enables it by default in all zones except the Restricted sites zone, where it is disabled. This is an acceptable default. However, if you are worried about a widespread, malicious IE vulnerability that can be stopped by disabling this option, consider disabling this option until a patch or other alternative defense can be applied.

Downloads-Automatic Prompting for File Downloads

This setting determines whether the user will be prompted by a pop-up dialog box for normal file downloads. In most cases, the answer should be yes. It is always nice to know when a Web site is trying to download content. If this option is disabled, and the next option is enabled, then the user will download and potentially execute files without a primary acknowledgement (although the user may be prompted to confirm a download location). That particular situation would be harder to defend. Microsoft disables this for all zones, except for the Local intranet. This option should be enabled on all zones.

Interestingly, when this setting is disabled, most file downloads still prompt the user before proceeding. Internet Explorer contains a hard coded list of file types (by file extension) that the warning dialog box cannot be disabled for. They are:

  • ASP

  • BAS

  • BAT

  • CHM (IE5 only)

  • CMD

  • COM

  • EXE

  • LNK

  • INF

  • REG

  • ISP

  • PCD

  • MST

  • PIF

  • SCR

  • HLP

  • HTA (IE5 only)

  • JS

  • JSE

  • URL

  • VBS

  • VBE

  • WS

  • WSH

Downloads-File Download

Disabling this option prevents all file downloads. If the previous option is enabled, it is usually safe to enable this option. Microsoft enables this option in all zones, but in the Restricted sites zone where it is disabled. The defaults are acceptable.

Downloads-Font Download

This option determines whether IE HTML fonts, normally needed for the correct presentation of a web page, can be downloaded automatically. It is enabled in all zones by default, except the Restricted sites zone where it is set to Prompt. The default settings are good.

Enable .Net Framework Setup

If enabled, this will prevent .NET Framework from being installed. It is enabled in all zones except Restricted sites.

Java VM-Java Permissions

This setting will not appear unless the Java Virtual Machine (JVM) component has been installed. Microsoft's default settings are acceptable.

Miscellaneous-Access Data Sources Across Domains

This setting determines whether a web page can retrieve data from another server located in a different domain. If set to disabled, it will only allow data to be retrieved from the same server the originating web page is being served from or from another server in the same domain. A few exploits have been accomplished when this setting is enabled. Most Web sites access data on servers in the same domain. If this feature is not needed, keep it disabled. Microsoft disables it in most zones, but prompts it in the Local intranet zone. The default settings are acceptable in most cases.

Miscellaneous-Allow META REFRESH

A Meta-Refresh is an HTML command that instructs a browser to refresh the current web page after a periodic interval. It can also be used to re-direct a user, without their permission, to another web page. It has been used maliciously many times, but as long as other critical vulnerabilities are patched, there is little risk. Legitimate use of Meta-refreshes is common. Microsoft enables this option in all zones, but the Restricted sites zone. The default option is normally okay.

Miscellaneous-Allow Scripting of Internet Explorer Web Browser Control

This is a new option in IE 6.x XP SP2, although the control is not. The Web browser control is a stand-alone ActiveX control that can be used by programmers to add a mini-HTML browser to their application. After a few vulnerabilities were found by enabling this option by default, Microsoft disables it in all zones except for the Local intranet. The default option is acceptable.

Miscellaneous-Allow Script-Initiated Windows Without Size or Position Constraints

This option determines whether or not a Web site can open a new IE window anywhere and of any size. Unscrupulous web advertisers often make oddly sized browser screens (i.e. either very small or very large) to make it difficult on the user to close the pop-up advertising window. It is disabled by default in all zones except Restricted sites. This is an acceptable default choice.

Miscellaneous-Allow Web Pages to Use Restricted Protocols for Active Content

You can define, in the zone registry settings, which protocols and port numbers are allowed in a particular zone. Using this setting you can define whether or not Web sites in this zone can use protocols and port numbers not explicitly defined in the registry. Microsoft has this option set to Prompt in most zones, and disabled in the Restricted sites. The default options are acceptable.

Miscellaneous-Allow Websites to Open Windows Without Address or Status Bars

Many malicious Web sites and adware try to fool users by opening windows without addresses or status bars. This is disabled for Internet and Restricted sites zones, and enabled for Local intranet and Trusted Sites zones. The defaults are acceptable.

Miscellaneous-Display Mixed Content

This option determines whether or not you will be prompted if a web page tries to display content from a HTTP and HTTPS communications streams at the same time. In IE 6, if it was set to Prompt, they could receive the following "Security Information" message on the web pages that contain both secure (https) and nonsecure (http) content:

     This page contains both secure and nonsecure items.

     Do you want to display the nonsecure items?

This is a very common occurrence on HTTPS Web sites, although to be truly secure they should never mix content types. All but the security paranoid disable this feature, even though Microsoft's default on all zones is Prompt. The default is acceptable unless you are particularly worried about spoofed HTTPS Web sites.

This option has been enhanced in IE 7 and users will no longer see the mixed-content dialog box prompt shown previously. IE7 will only render the secure content by default, and offers the user the opportunity to unblock the not secure content using the new Information Bar. This is an excellent change because in previous versions of IE, the user was asked the question without really knowing the difference between the secure and not secure content. Now, they will see the secure content first, separated from the non-secure content. Besides preventing some types of malicious attacks, it will prevent a lot of Web site advertising.

Miscellaneous-Don't Prompt for Client Certificate Selection When No Certificates or Only One Certificate Exists

This setting was introduced in IE 5.5 SP1. When this option is set to Enable, IE does not prompt the user with a "Client Authentication" message when it connects to a Web site that has no certificate or only one certificate. When Disabled, IE will display the following "Client Authentication" message even if the Web site does not have a certificate or has only one certificate:

     Identification

     The Web site you want to view requests identification.
     Select the certificate to use when connecting.

Microsoft enables it in the Local intranet zone and disables elsewhere. This is an acceptable setting, although it also means that you may be sending your identity to the connected server.

Miscellaneous-Drag and Drop or Copy and Paste Files

Determines whether files and folders can be dragged and dropped between client and server, or whether files and folders can be copied and pasted between client and server. Strangely, if disabled in the Internet zone, it will not allow the described options between mapped drives on your computer if the NetBIOS shares were mapped using IP addresses instead of names. Dragging and dropping files is also helpful for FTP and WebDAV operations. Microsoft enables this setting in all zones except Restricted sites, where it is set to prompt. There is little misuse possible, so the defaults are acceptable. The one attack type the authors are aware of involves a timing attack where the user is tricked into overwriting an unintended file in an unintended location. This has been proven in theory, and even demonstrated a few times. However, this type of attack has never been used in a widespread manner, so Prompt should be acceptable.

Miscellaneous-Include Local Directory Path When Uploading Files to a Server

Enabled on all zones except for Restricted sites by default, it passes along the local directory path when uploading files using HTTP or FTP (within IE). Defaults are acceptable.

Miscellaneous-Installation of Desktop Items

Determines whether or not a Web site can install shortcuts and content to the user's desktop. Should be disabled or set to Prompt in most zones. Microsoft set it to Prompt in all zones, except for the Restricted sites zone, where it is disabled. The defaults are acceptable.

Miscellaneous-Launching Applications and Unsafe Files

Determines whether or not the hard coded file types listed previously can be launched or their associated programs executed. This is Enabled on the Local intranet, disabled on Restricted sites zone, and set to Prompt on the Internet and Trusted Sites zones. The defaults are acceptable.

Miscellaneous-Launching Programs and Files in an Iframe

Determines whether programs and files can be executed in an inline floating IE frame (IFRAME). Several vulnerabilities have used this feature over the years. It should be set to Prompt or Disabled. Microsoft sets it to prompt in all zones except where it disables it in the Restricted sites zone. The defaults are acceptable.

Miscellaneous-Navigate Sub-Frames Across Different Domains

Determines whether it is possible to open up a child sub-frame that references a server located in a different domain than its parent. A malicious Web site could mimic a legitimate Web site by inserting a window as a frame within the legitimate Web site's window. This feature was used in a few exploits years ago, but now is not considered overly dangerous. Microsoft disables this setting in all zones, except for the Local intranet zone. I prefer to set the option to Prompt in the Internet zone for usability reasons.

Miscellaneous-Open Files Based on Content, Not File Extension

This option determines whether IE will read the first 200 bytes of a file's header to determine if the file meets the MIME Type the Web site claims it to be. If the extension matches the MIME type, IE does not check the file header. But if there is a disagreement, IE reads the file header in an attempt to determine the correct MIME Type. It has been enabled in all zones except for the Restricted sites zone. We would Enable it there as well.

Miscellaneous-Software Channel Permissions

This setting specifies the computer's level of access for Web-based software distribution channels. The possible values are: High Safety/Low Safety/Medium Safety

  • High Safety: Prevents users from being notified about software updates by e-mail, software packages from being automatically downloaded to users' computers, and software packages from being automatically installed on users' computers.

  • Medium Safety: Notifies users about software updates by e-mail, and allows software packages to be automatically downloaded to (but not installed on) users' computers. The software packages must be validly signed; users are not prompted about the download.

  • Low Safety: Notifies users about software updates by e-mail, allows software packages to be automatically downloaded to users' computers, and allows software packages to be automatically installed on users' computers.

The Internet zone and Local intranet zones are set to Medium safety. The Trusted Sites zone is set to Low safety. The Restricted sites zone is set to High safety. The selections are reasonable.

Miscellaneous-Submit Non-Encrypted Form Data

This option determines whether HTML pages in the zone can submit unencrypted forms to or accept unencrypted forms from servers in the zone. Forms sent using SSL are always allowed. This option is usually enabled, except for Restricted sites where it is set to Prompt. The defaults are good.

Miscellaneous-Use Phishing Filter

Enabling this filter tells IE 7 to send each new domain URL to Microsoft's anti-phishing servers for inspection before allowing the page to be displayed. If a site has been defined as fraudulent, the user is warned. It slows down web surfing, but increases security significantly. It should be enabled on zones except Local intranet sites (because it isn't needed and only affects performance), and these are the Microsoft defaults.

Miscellaneous-Use Pop-Up Blocker

Determines whether the built-in pop-up blocker is turned on. As with the previous setting, this should be enabled for all zones, except the Local intranet. This is the Microsoft default, as well.

Miscellaneous-Userdata Persistence

Determines whether a Web site can save a data about the user or the current session on the user's hard drive, much like a cookie would be able to do. This feature is used by many legitimate Web sites, and although it can possibly be used maliciously, it's best to leave it turned on. The mischief caused by enabling this is limited to tracking-no code execution or exposure of local data (unless you count browsing habits). Microsoft leaves it turned on by default for all zones, but the Restricted sizes zone and this is acceptable.

Miscellaneous-Web Sites in Less Privileged Web Content Zone Can Navigate into This Zone

This setting prevents less privileged content from initiating new connections into higher privileged zones. This was created to defeat a new type of malicious attack. Microsoft has this option enabled in most zones, but disabled in the Restricted sites zone. It should be disabled by default in the Internet zone.

Scripting-Active Scripting

This setting determines whether scripting is allowed in IE. If turned off, this disables JavaScript and VBScript engines. Although many IE exploits rely on scripting to work, so do most Web sites. Leave this enabled unless you are trying to defend against a widespread attack that cannot be stopped by using alternative defenses. Microsoft enables on all zones except the Restricted sites zone and this is acceptable.

Scripting-Allow Programmatic Clipboard Access

In previous versions of IE, a malicious Web site could script language to copy the data last used in the Clipboard application (from user's Edit, Copy, Edit, Paste operation) to their Web site. Users and administrators often use the Clipboard to copy long and complex passwords during a logon sequence. This vulnerability could potentially let a malicious Web site see confidential data.

This option used to be called "Allow paste operations via script" in previous versions. See http://www.sourcecodesworld.com/special/clipboard.asp to determine if your browser is vulnerable to paste operations manipulations. In IE 6, Microsoft enabled this option in all zones except the Restricted sites zone. In IE 7, this value is set to Prompt in the Internet and Trusted Sites zones, enabled in the Local intranet zone, and Disabled in the Restricted sites zone. It should be disabled on all zones unless needed. When set to prompt, the user will see a dialog box, similar to Figure 8-14, when a Web site attempts to access the Clipboard.

Image from book
Figure 8-14: Internet Explorer asking for confirmation before letting a Web site use the Clipboard for pasting operations
Note

A developer, malicious or legitimate, can add their program's executable to the \HKLM\Software\Microsoft\Windows\Internet Explorer\Main\FeatureControl\registry key (see http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/cols/dnexpie/clipboard_scriptaccess.asp for more details) to bypass the warning prompts.

Scripting-Allow Status Bar Updates Via Script

This option determines whether a Web site can update the status bar using a script. Some malicious Web sites use scripts to fraudulently modify IE's status bar, such as indicating whether SSL is enabled or not. It is correctly disabled for Internet and Restricted sites zones.

Scripting-Allow Websites to Prompt for Information Using Scripted Window

This setting determines whether a Web site can query IE for personal information (for example, your e-mail address). Microsoft has appropriately turned it off in the Internet and Restricted sites zones.

Scripting-Scripting of Java Applets

This determines whether Java applets can be scripted. Although there have been dozens of Java exploits found over the years, only one has ever been widespread. The overall risk is low. You can enable the scripting of Java applets on all zones except the Restricted sites zone, which is the Microsoft default.

User Authentication

Last, this option determines how IE responds to a request for the browser to authenticate the user. In previous versions of IE, IE would always respond to authentication requests by trying to log in with the current user's name and password. Unfortunately, it is possible for malicious Web sites to force unprotected Windows computers to use older, weaker authentication protocols (LAN Manager), which are easy to crack.

A common ploy for a spammer was to send the victim a spam e-mail that contained a 1-pixel graphic (called a web spider or beacon) that needed to be downloaded from the spammer's malicious web server to display in the e-mail. Previous versions of Outlook and Outlook Express would attempt to download the graphic automatically to display in the e-mail. The hostile Web site would request user authentication to download the web spider, and tell the victim's computer that it only understands the LM authentication protocol. Thus, all the victim did was open an e-mail and their computer was sending back their login name and password in an easily hackable format.

Now IE will only send the user's current logon name and password if the site is listed in the user's Local intranet sites zone. Otherwise, IE will try to logon anonymously or prompt the user for their logon name and password. IE's default settings are acceptable.

Table 8-2 summarizes IE's default zone security settings. We make practical recommendation changes as highlighted in parenthesis where appropriate.

Table 8-2: Summary of Internet Explorer 7's Security Zone Settings Open table as spreadsheet
DEFAULT SETTING PER ZONE (AND RECOMMENDATION IF THEY VARY FROM MICROSOFT'S DEFAULTS)
SETTING | INTERNET | LOCAL INTRANET | TRUSTED SITES | RESTRICTED SITES
Default Security level | Medium-High | Medium-Low | Medium | High
Protected Mode | On | On | Off | Off
.NET Framework-Loose XAML | Enable | Enable | Enable | Disable
.NET Framework-XAML browser applications | Enable | Enable | Enable | Disable
.NET Framework-XPS documents | Enable | Enable | Enable | Disable
.NET Framework-reliant components-Run components not signed with Authenticode | Enable (Disable or Prompt) | Enable (Disable or Prompt) | Enable (Disable or Prompt) | Disable
.NET Framework-reliant components-Run components signed with Authenticode | (Enable Prompt) | Enable | Enable | Disable
ActiveX controls and plug-ins-Allow previously unused ActiveX controls to run without prompting | Disable | Enable | Enable | Disable
ActiveX controls and plug-ins-Allow Scriptlets | Disable | Enable | Disable | Disable
ActiveX controls and plug-ins-Automatic prompting for ActiveX controls | Disable | Enable | Disable | Disable
ActiveX controls and plug-ins-Binary and script behaviors | Enable (Disable or Prompt) | Enable (Disable or Prompt) | Enable (Disable or Prompt) | Disable
ActiveX controls and plug-ins-Display video and animation on web page that does not use external media player | Disable | Disable | Disable | Disable
ActiveX controls and plug-ins-Download signed ActiveX controls | Prompt | Prompt | Prompt | Disable
ActiveX controls and plug-ins-Download unsigned ActiveX controls | Disable | Disable | Disable | Disable
ActiveX controls and plug-ins-Initialize and script ActiveX controls not marked safe for scripting | Disable | Disable | Disable | Disable
ActiveX controls and plug-ins-Run ActiveX controls and plug-ins | Enable | Enable | Enable | Disable
ActiveX controls and plug-ins-Script ActiveX controls marked safe for scripting | Enable | Enable | Enable | Disable
Downloads-Automatic prompting for file downloads | Disable (Enable) | Enable (Enable) | Disable (Enable) | Disable
Downloads-File download | Enable | Enable | Enable | Disable
Downloads-Font download | Enable | Enable | Enable | Disable
Enable .NET Framework setup | Enable | Enable | Enable | Disable
Java VM-Java Permissions* | High safety | Medium safety | High safety | Disable Java
Miscellaneous-Access data sources across domains | Disable | Prompt | Disable | Disable
Miscellaneous-Allow META REFRESH | Enable | Enable | Enable | Disable
Miscellaneous-Allow scripting of Internet Explorer web browser control | Disable | Enable | Disable | Disable
Miscellaneous-Allow script-initiated windows with size or position constraints | Disable | Enable | Disable | Disable
Miscellaneous-Allow web pages to use restricted protocols for active content | Prompt | Prompt | Prompt | Disable
Miscellaneous-Allow Web sites to open windows without address or status bars | Disable | Enable | Enable | Disable
Miscellaneous-Display mixed content | Prompt | Prompt | Prompt | Prompt
Miscellaneous-Don't prompt for client certificate selection when no certificates or only one certificate exists | Disable | Enable | Disable | Disable
Miscellaneous-Drag and drop or copy and paste files | Enable | Enable | Enable | Prompt
Miscellaneous-Include local directory path when uploading files to a server | Enable | Enable | Enable | Disable
Miscellaneous-Installation of desktop items | Prompt | Prompt | Prompt | Disable
Miscellaneous-Launching applications and unsafe files | Prompt | Enable | Prompt | Disable
Miscellaneous-Launching programs and files in an IFRAME | Prompt | Prompt | Prompt | Disable
Miscellaneous-Navigate sub-frames across | Disable (Prompt) | Enable | Disable | Disable
Miscellaneous-Open files based on content, not file extension | Enable | Enable | Enable | Disable (Enable)
Miscellaneous-Software channel permissions | Medium safety | Medium safety | Medium safety | High safety
Miscellaneous-Submit non-encrypted form data | Enable | Enable | Enable | Prompt
Miscellaneous-Use Phishing Filter | Enable | Disable | Enable | Enable
Miscellaneous-Use Pop-up Blocker | Enable | Disable | Enable | Enable
Miscellaneous-User data persistence | Enable | Enable | Enable | Disable
Miscellaneous-Web sites in less privileged web content zone can navigate into this zone | Enable (Disable) | Enable | Enable | Disable
Scripting-Active Scripting | Enable | Enable | Enable | Disable
Scripting-Allow Programmatic clipboard access | Prompt (Disable or Prompt) | Enable (Disable) | Prompt (Disable) | Disable
Scripting-Allow status bar updates via script | Disable | Enable | Enable | Disable
Scripting-Allow Web sites to prompt for information using scripted window | Disable | Enable | Enable | Disable
Scripting-Scripting of Java applets | Enable | Enable | Enable | Disable
User Authentication | Automatic only in Intranet zone | Automatic only in Intranet zone | Automatic only in Intranet zone | Prompt for username and password

IE Advanced Settings

Advanced settings apply consistently across all IE security zones. Some of the settings complement or override the options available in the separate security zones. In general, settings chosen here win over the individual settings in the security zones (but not always). For that reason, a user or administrator must be aware not to set configuration options in conflict with one another. These issues are noted when applicable.

There are over 60 different Advanced settings in IE 7. This section of the chapter will cover only the settings that can purposely affect IE's overall security.

Browsing-Disable Script Debugging (Internet Explorer or Other)

This is two separate options that tell IE whether or not to check for script errors. If enabled, as is the default, it disables this ability. This is usually only useful for programmers. If enabled, IE warns the user when script errors are located. Malicious Web sites often have code bugs so disabling this feature would show an interested programmer the coded mistake automatically, if they wanted to know. The delineation between IE script debugging and other foreign debuggers is new to the latest versions of IE.

Browsing-Display a Notification About Every Script Error

If enabled, IE displays a notification message about every error it encounters in a script. It is disabled by default and this is usually an acceptable choice. Like the last option, there is little to gain by enabling this feature unless the user is a programmer and looking for security coding issues.

Browsing-Enable Third-Party Extensions

Extensions allow a browser's functionality to be enhanced and extended. Although many legitimate programs install extensions, so too does malware, spyware, and adware. Microsoft enables this by default. If legitimate extensions are not needed, disable.

Browsing-Use Inline Autocomplete

Disabled by default, this feature determines whether IE's AutoComplete feature (which automatically tries to fill in requested information, such as a user's name and address) does so when a Web site form requests stored information. It can be used maliciously by a remote Web site by tricking the browser into serving up otherwise confidential information or locally by an unauthorized user. Keep disabled unless needed.

International-Send UTF-8 URLS

UTF-8 encoding allows a user to use URLs that include non-ASCII and foreign language characters, regardless of the language of the user's' operating system and browser language. Without UTF-8 encoding, a web server must be based on the same language code page as that of the user's to correctly render URLs containing non-ASCII or foreign characters. Disabling would prevent some URL obscurity spoofing attacks, such as the double-byte encoding, but would cause problems with many legitimate Web sites. Microsoft has it enabled by default and it should probably stay that way.

Java (or Java-Sun)-Use JRE x.x for <applet>

Only appears if a Java Virtual Machine (JVM) environment is installed. There is some additional risk from running Java, but if you keep Java patched, you can leave this option enabled. Often needed for legitimate Web sites. If you use Java, make sure to keep up on the latest Java JVM and patches.

Security-Allow Active Content from CDs to Run on My Computer

A new IE setting. Determines whether browser content can run in the Local Computer zone if launched from local CDs. If disabled, active content runs in the Internet zone. Leave disabled unless needed.

Security-Allow Active Content to Run in Files on My Computer

A new IE setting. Determines whether browser content can run in the Local Computer zone if launched locally. If disabled, all active content runs in the Internet zone. It has often been the cause of many exploits. Leave disabled unless needed.

Security-Allow Software to Run or Install Even If the Signature Is Invalid

Disabled by default and should be left that way. If enabled, allows unsigned and untrusted software to run.

Security-Check for Publisher's Certificate Revocation

Enabled by default and should be left enabled. Checks to see if the publisher's (that is, software vendor who signed the program) digital certificate has been revoked by the Certificate Authority (CA). You would never want to run a program whose publisher's certificate was revoked. This could mean that the publisher's private key was stolen and has been fraudulently used to sign a malicious executable.

Security-Check for Server Certificate Revocation

If enabled, and it is by default, IE will check to see if a server's SSL or TLS digital certificate is revoked, during the initial handshake connection to a HTTPS Web site. However, it is not uncommon for many legitimate Web sites' revocation to "fail" for one reason or another. Usually it is because the revocation link (called the certificate revocation link distribution point) is unreachable at the moment or not defined correctly.

If the Web site is legitimate and the digital certificate it gave is legitimate, you can usually choose to ignore the certificate revocation message. Usually the additional warning messages, if they occur, encourages users to further verify the SSL connection status. And anything that makes the end user more involved in verifying digital certificates without always accepting them by default is a good thing.

Security-Check for Signatures on Downloaded Programs

This option is enabled by default and should remain that way. It ensures that any downloaded programs have verified digital signatures or else displays a warning about what is invalid about the digital certificate (or the digital signature may be missing all together). An invalid or missing digital signature means the software is at a higher risk for maliciousness, albeit, remembering that most downloadable software on the Internet is not signed.

Security-Do Not Save Encrypted Pages to Disk

Disabled by default, this option ensures that pages encrypted by SSL/TLS are also stored encrypted on the local disk. This option can be left disabled in most organizations unless the security risk of a local intrusion is higher than average. Normally, in order for an intruder to search and find downloaded Internet content belonging to another user, they must have admin rights to search the user's profile. If the intruder has local admin rights, this is just one of the many attacks that they can launch. Still enabling this security option causes only slightly higher disk and CPU utilization. Most administrators only turn it on computers with shared access.

Security-Empty Temporary Internet Files Folder When Browser Is Closed

As with the previous option, this feature is disabled by default and only needs to be enabled if local admin attack risk is higher than normal. If turned on, the TIF area will be deleted every time IE is closed. This option does have a moderate to substantial performance penalty during the erasing actions. Most administrators only turn it on computers with shared access.

Enable Memory Protection to Help Mitigate Online Attacks

IE's main executable, Iexplore.exe, is not protected by Data Execution Protection (DEP), although on a positive note, it is enabled for Ieuser.exe and Ieinstal.exe. We recommend that you enable DEP protection for Iexplore.exe, unless you use a conflicting add-on (e.g. Java). To enable DEP protection for IE, start IE in admin mode, click on the Tools menu option, and choose the Advanced tab under the Internet Options menu selection. Then, enable the Enable memory protection to help mitigate online attacks.

Security-Enable Integrated Windows Authentication

This setting works in conjunction with the security zone setting, User Authentication, which defines whether authentication would happen automatically or not, and to which zones. This setting determines whether Windows logon authentication can be used, if prompted.

There are four types of Windows logon authentication protocols: LM, NTLM, NTLMv2, and Kerberos. If this feature is enabled, which it is in IE 7, users can logon using Windows authentication to Web sites that support integrated Windows authentication (such as IIS). The integrated login presents the user's currently logged in name and password for authentication if requested. If the related zone setting is set to automatic, the authentication occurs without the end user having even been aware of the exchange. If the automatic authentication has not been approved, the user will be prompted for logon credentials.

By default, all newer versions of IE will connect to all web servers using anonymous authentication first. If the web server requires Windows logon authentication, in most cases the user will be prompted for a logon name and password unless they are connecting to an intranet site. When enabled, the automatic use or prompting of integrated login can be controller by IE security zone. Even if this feature is turned on, Windows logon authentication methods normally only work on the local network (or forest), and over VPNs; and are not normally allowed over the Internet (without much planning, configuration, and management).

Although there is little risk to most environments by enabling this feature, you can leave it disabled unless needed. Remember to turn it on if needed (i.e., for SharePoint Services, IIS, and so on). If allowed to non-intranet sites, disable the use of LM and NTLM authentication protocols (discussed in Chapter 3) to prevent malicious remote Web sites from requesting insecure versions of user logon credentials.

Security-Phishing Filter Settings

New with IE 7, this option enables or disables IE's new anti-phishing filter option. We can think of no reason to disable it, other than the 1–2 second delay it incurs sometimes on new Web site connections.

Note

Occasionally, the phishing filter will not check on the Web site and report whether the Web site is a known phishing site until many seconds after the web page is loaded. It might appear as if a web page is not a suspected phishing site, and then 2–10 seconds later the Web site is accurately marked as a known phishing site. This may be a result of the performance trade-offs allowing the Web site to load during the same time the filter check is made, meaning that there is the slight chance that a user could use the malicious web page for a few seconds prior to the warning.

The three Phishing Filter options are as follows:

  • Check Web sites Automatically

  • Do Not Check Web sites Automatically

  • Turn off Phishing Filter

If you turn the filter off completely, the Check This Website option, which can be done manually on a per-site basis, is disabled. Choose the Do Not Check Websites Automatically option if you want to allow per-site manual checking. I frequently use the Report This Website option to report phishing and fraudulent Web sites to Microsoft to benefit other users. After reporting the suspected Web site, it goes through a review process before being made available as a confirmed phishing site to other users.

The anti-phishing filter can also be enabled or disabled using IE zone security settings. If the phishing filter is turned off in Advanced settings, it overrides settings (s) in the separate security zones.

Security-Use SSL 2.0, SSL 3.0, TLS 1.0

This option determines what version of SSL is allowed or if Transport Layer Security (TLS) is enabled. SSL 2.0 is disabled by default, but the other two options are enabled. TLS is the next version of SSL. (There will be no SSL 4.0 standard.) It works more securely at a lower layer of the OSI model and has many improved security features. SSL 2.0 should be disabled. There are a few Web sites still using it, but the overall percentage is not overwhelming. All the good commercial sites have long supported SSL 3.0 and above.

Security-Warn About Invalid Site Certificates

This option is enabled by default and warns the user if a web server's digital certificate is invalid (if SSL/TLS are enabled in the previous setting). Legitimate sites with invalid certificates abound, unfortunately, usually because of expired useful life dates or because the current Web site doesn't make the certificate's Web site address. Still, warning users that a digital certificate is invalid raises awareness and may alert them to a spoofing or man-in-the-middle attack.

Security-Warn If Changing Between Secure and Not Secure Mode

This setting determines whether or not IE will notify the user that they are being directed between SSL/TLS and non-SSL/TLS sites. The default option of Enabled is acceptable.

Security-Warn If Forms Submittal Is Being Redirected

As with the separate identical security zone setting, this option determines whether the user will be notified that the data they are submitting to a Web site is being redirected to another Web site. Although this can occur on legitimate Web sites, the default option of Enabled should be left turned on to warning users of spoofing or man-in-the-middle attacks. There is a similar (but different) zone setting, which determines if the user can submit forms data unencrypted or not.

Table 8-3 summarizes IE 7's default settings.

Table 8-3: Internet Explorer 7's Default Advanced Setting Values Open table as spreadsheet
ADVANCED SETTING | DEFAULT SETTING
Browsing-Disable Script Debugging (Internet Explorer or Other) | E
Browsing-Display a notification about every script error | D
Browsing-Enable third-party browser extensions | E
Browsing-Use inline AutoComplete | D
International-Send UTF-8 URLs | E
Java (or Java-Sun)-Use JRE x.x for <applet> | E (if Java installed)
Security-Allow active content from CDs to run on My Computer | D
Security-Allow active content to run in files on My Computer | D
Security-Allow software to run or install even if the signature is invalid | D
Security-Check for publisher's certificate revocation | E
Security-Check for server certificate revocation | E
Security-Check for signatures on downloaded programs | E
Security-Do not save encrypted pages to disk | D
Security-Empty Temporary Internet Files folder when browser is closed | D
Security-Enable Integrated Windows Authentication | E
Security-Phishing Filter Settings | Check Web sites Automatically
Security-Use SSL 2.0, SSL 3.0, TLS 1.0 | D, E, E
Security-Warn about invalid site certificates | E
Security-Warn if changing between secure and not secure mode | E
Security-Warn if forms submittal is being redirected | E

Other Browser Recommendations

IE is a complex piece of popular software. Hackers are never going to stop attacking it, and it is unlikely to suddenly become unexploitable. Odds are that IE will always remain one of the most exposed and attacked pieces of software in Microsoft's platform. Still, running IE doesn't mean getting a guaranteed successful attack. Here are the many defenses you can take to prevent IE exploitation, going from most useful to least.

Don't Browse Untrusted Web Sites

The number one way to prevent malicious exploitation is to not visit unknown and untrusted Web sites. Don't click on "weird" links sent to you in e-mail. Look out for strange looking phishing URLs. Too many encoded characters or sound-alike names and URLs should set off warning bells. Any company asking for your financial information unexpectedly is probably a fraud. Verify your SSL links by scrutinizing the accompanying digital certificate. Make sure all the information is valid and points to the correct Web site. IE 7, with its anti-phishing filter, is making great strides in preventing users from visiting fraudulent Web sites. But fake Web sites can be made in seconds, and more than likely always stay well ahead of IE's real-time checking behavior.

If you just have to visit a non-trusted Web site, consider running the IE session in a virtual environment like Microsoft's Virtual PC or VMware's VMWorkstation. That way if anything ugly happens, you can reset the session and minimize the potential risk to the real underlying OS. Microsoft has already released the Shared Computer Toolkit for Windows XP (http://www.microsoft.com/windowsxp/sharedaccess/overview.mspx), which, among other features, prevents permanent changes (i.e., made by malware) from being saved in between reboots. Also, consider using a less functional alternate browser or one that has been set to run no active content at all (for example, Lynx) when visiting unknown Web sites.

Many people run less functional browsers all the time in the hope that it will prevent malicious exploitation. While it may minimize the risk, at the expense of functionality, IE's coding cannot be removed from Windows. Even when you run an alternate browser, it is very possible for a malicious program to call IE's coding (for example, via e-mail, embedded link in Microsoft Office, and so on). So, even if IE isn't your main browser, be sure to install all patches and updates. Not doing so, even if you don't use it, increases exposure risk.

Keep IE Patches Updated

Once you are running IE 6.x or 7.x, keep on top of the patches. Patch any critical patches as soon as you can after testing. These days many IE exploits are getting released within three days of patch announcement. In the past you could afford to wait a few weeks. No longer. Immediate testing and deployment of critical patches should be a priority of any organization.


Will Internet Explorer 7 Be Hacked A Lot?

Of course. Whatever is popular gets hacked. Even IE in Protected Mode has enough allowed low integrity locations that malware and hackers will discover ways to launch malicious code without having to write to the previous system locations. Malware may not be able to modify files in \Windows or \System32, but malware writers will find a way to exploit IE 7.

The hope is that it will be harder for malware writers to make successful attacks and be easier for Microsoft to patch. Some Microsoft critics think that IE is too complex and buggy to ever be secure. IE 7 will be tested heavily over the next few years to see if Microsoft can make a more secure browser than versions in the past.


Summary

Internet Explorer is significantly more secure than Microsoft's previous browser versions. It has dozens of new security features and stronger default settings. The main new features are Protected Mode, Anti-Phishing filter, Addon Management, better ActiveX control, and improved digital certificate handling. IE should make drive-by-downloads more difficult to pull off for malicious hackers. However, IE is one of the most attacked pieces of software in the world. The weaknesses covered in this chapter, plus other ones that hackers are sure to come up with, mean that IE will continue to be successfully hacked in the future. The real question is whether IE 7 in Vista will result in less successful vulnerabilities, and of lower criticality, than its predecessors.

Chapter 9 will cover Internet Information Service 7.


Best Practices

Assuming you're going to run Internet Explorer 7 on a PC that can connect to the Internet, here are some best practices to follow:

  • Configure Internet Explorer's security zone settings to be as secure as is practical in your environment.

  • Change Allow Binary Behaviors to Prompt from Allow.

  • Disable or prompt for unsigned .NET Framework Components.

  • Disable or uninstall Java if it's not needed.

  • If Java is needed, make sure only the latest version is installed (i.e., newer Java upgrades often leave the old version installed, too).

  • Ensure Internet Explorer is fully patched at all times.

  • Make sure Protected Mode is enabled.

  • Ensure the Internet zone uses Medium-Low security, or Low.

  • Enable the Phishing Filter.

  • Disable unnecessary add-ons using Internet Explorer's security settings or user group policy.

  • Disable or remove unneeded ActiveX controls.

  • Don't allow users to add unauthorized Trusted Root Certification Authorities.

  • Don't allow end users to save passwords for Web sites.

  • Educate end users about browser threats.

  • Tell end users to never use passwords (for example, to check e-mail) from public kiosk computers where a malicious keylogger could be installed.

  • Remind users not to visit malicious Web sites.

  • Enable DEP protection for 32-bit versions of Internet Explorer if Java or other incompatible applications are not used.

Disable HTML rending in e-mail (covered in Chapter 10).


Chapter 9: Introducing IIS 7

Windows Vista introduces Internet Information Service (IIS) 7, built on Microsoft's highly successful IIS 6 product. After over four years (IIS 6 was released in March 2003 along with Windows Server 2003), IIS 6 remains without a single significant security blemish. IIS 7 was created to be even more secure. This chapter covers web server threats, introduces the new features and changes of IIS 7, and concludes with the ways to harden an IIS 7 server.

Note

IIS 7 is secure by default. This chapter's recommendations provide additional hardening steps applicable to any environment to make it even tougher to hack a web server. IIS 7 was specifically designed to be tough enough to serve as any type of web server, whether used internally as an intranet site or as an externally facing Internet-accessible web server. This chapter will cover hardening steps that can secure both types. However, IIS 7's original presence on Windows Vista, an end-user client OS, indicates that Microsoft intended IIS 7 to initially lean more toward intranet use.

Web Server Threats

Web servers contain many pieces and parts, including the host OS, web protocols, back-end databases, and the web server software itself. This collection of related components coupled with inviting inbound Internet connectivity makes web servers a frequent hacker target. Threats to web servers include the following:

  • Application vulnerabilities

  • OS vulnerabilities

  • Back-end database issues

  • Protocol vulnerabilities

  • Buffer overflows

  • Directory traversal attacks

  • Sniffing attacks

  • Denial of service

  • Password-guessing attacks

Each of those threat types is covered in slightly more detail in the material that follows.

Application Vulnerabilities

Application vulnerabilities account for the vast majority of web server attacks. OS and web server vendors have worked hard to make their products less exploitable but, in general, application developers tend to be under trained in security. To be fair, most managers are more focused on delivering applications on time than with developing and testing the security defense of the application against some "theoretical" attack.

Note

When hiring a PHP programmer, I asked every one of the two dozens candidates what they did to ensure that the PHP code that they wrote or borrowed did not contain security vulnerabilities. To a person, all claimed to be unaware that PHP had any security issues. Only one candidate even seemed interested in the subject. He got the job. This is a real-world example of why web applications continue to be the most frequent target of hackers.

Application vulnerabilities are often caused by incorrect permission setting, scripting errors, design faults, inadequate input parameter checking, and by coding errors in general.

No software programmer is perfect. All programmers make design or coding errors. It's a factor of being human. Coding errors are often measured in bugs per thousands of lines of code (or bugs per kloc). The average number of bugs per kloc for a programmer is thought to be between 50–150/kloc, according to several studies. One study (http://www.sei.cmu.edu/news-at-sei/columns/watts_new/2004/3/watts-new-2004-3.htm) of 800 industrial programmers revealed in a 120 bugs/kloc average. The top 1 percent most accurate coders had 11 bugs/kloc.

Microsoft has worked hard to reduce the number of bugs through better programmer training, manual and automated code review, and financial incentives. According to David LeBlanc, Senior Software Development Engineer in the Office Division of Microsoft, the results are paying off. Microsoft believes their core programmers program to a 5 bugs/kloc standard, the best of any large company. Of course, Windows Vista contains over 50,000,000 lines of code. If you assume 5 bugs/kloc average, it means Vista could be estimated to have 250,000 programming bugs. Still, most of them are not security issues. They are more likely to be reliability and user-friendliness issues.

Proof of Microsoft's software quality engineering processes is that IIS 6 has had only three known bugs (as of April 2007) since its release in March 2003, and neither was used a lot in the wild. Microsoft SQL, often paired with IIS, hasn't had a major exploit since the SQL Slammer worm in April 2003, and even that bug had been patched for over six months before the worm got out.

OS Vulnerabilities

All web server software runs on top of a host operating system. Accordingly, any successful attack against the underlying host OS is a successful attack against the web server. With the notable exception of OpenBSD (http://www.openbsd.org) every host OS has multiple vulnerabilities, including Windows. A web developer must take great care in hardening the underlying OS to minimize overall vulnerabilities.

Back-End Database Issues

Back-end databases, such as MS-SQL, MySQL, PostGres, and Oracle, are frequently the targets of intruder attacks because they often directly interface with front-end web servers. Although MS-SQL hasn't had a major system vulnerability in over three years, many other database suites, including Oracle and MySQL, have.

More often, application-level vulnerabilities (SQL injection attacks, scripting subsystem holes, and so on) allow the attacker to compromise the back-end database server and then use the data connection to compromise the web server.

Protocol Vulnerabilities

Web servers use a number of network, transport, and session protocols. The two most popular protocols used are Hypertext Transfer Protocol (HTTP) and HTTP over SSL (HTTPS). However, it would not be an exaggeration to say that a web server can utilize dozens of other protocols (and file formats) to serve up a standard application. Each protocol and the subsystem that interacts with the client is a potential attack vector.

Even when the protocol doesn't have known public vulnerabilities, web developers can implement them insecurely. It is not uncommon for Web sites claiming to have HTTPS encryption and authentication to send all resulting data streams in clear-text and unauthenticated.

Note

I have often seen this mistake on some of the Web's most popular banking and financial Web sites.

Buffer Overflows

Like any input-accepting application, web server software can be buffer overflowed. The most famous IIS buffer overflow was the Code Red worm of July 2001 (http://www.cert.org/advisories/CA-2001-19.html). Affecting IIS versions 4 and 5, its worldwide spread led to a major loss of consumer confidence in IIS. Microsoft responded by making the next release of IIS one of its most secure products in history. In over four years, only three holes have been found, none of which were used widespread.

The last one of those vulnerabilities (as of the book's publication date) was a buffer overflow exploit in July 2006 (http://www.microsoft.com/technet/security/Bulletin/MS06-034.mspx). IIS purists don't consider this an IIS buffer overflow because the exploit is located in the potentially separate ASP.NET subsystem. However, both products are made by Microsoft and are meant to be run together, although ASP.NET is not installed by default in IIS 6 unless intentionally enabled. Either way, it was not popularly exploited. Apache 2.0 web server, a popular open source web server, has had 4 buffer overflow vulnerabilities (out of 33 total known vulnerabilities) in roughly the same time period. Buffer overflows are a potential problem for all web servers.

Note

IIS's main executable, Inetinfo.exe, is protected by Data Execution Prevention (DEP), which will defeat many common buffer overflow attacks.

Directory Traversal Attacks

Directory traversal is an attack method in which the intruder uses malformed (or unexpected) input to "jump" out of the drive folder containing the web server program or application into more privileged areas. For instance, the default location for IIS application files is %Systemroot%\inetpub\wwwroot. A directory traversal attack would attempt to break out of the wwwroot folder into the root directory, \Windows, or \Windows\System32, where unauthorized access can be more successful and fruitful. Directory traversal attacks normally contain strings of characters (for example, http://../../../../../../../../) that attempt to confuse the web server into offering up an unauthorized default directory outside the normal web server boundary (see Figure 9-1). The attack allows the intruder to traverse various directories, go up to the root, and then back down into the drive's directory structure to execute contained commands.

Image from book
Figure 9-1: Representative example of a directory traversal attack

Although IIS has not experienced a successful directory traversal attack in many years, such attacks used to be a frequent method of exploitation in the days of Windows NT and IIS 4.

Sniffing Attacks

Unless the Web site uses HTTPS, the traffic to and from the web server is often sent in plain text. If the attacker can intercept the network streams, information can be sniffed and analyzed. Figure 9-2 shows a login name and password sniff from an HTTP session. Many users do not realize how frequently their confidential information is transmitted in clear text across the Internet.

Image from book
Figure 9-2: Example of clear text password caught in HTTP traffic

Denial of Service

Denial of service (DoS) attacks have been a big threat to web servers. Attackers, using armies of compromised machines, can send millions of rogue packets per second to a web server, denying legitimate access and business. DoS attacks are among the most popular attacks against popular, commercial web servers, and are rather difficult to prevent. Indeed, in some sense, they are impossible to prevent, as every communication begins with a request that causes a response. If an attacker can cause more malicious requests to come in than the host machine can adequately respond to, a DoS attack occurs. With the rise of botnets, networks of computers exploited and controlled by hackers, Distributed denial of service (DDoS) attacks make it possible for attackers to bring down even sites with large bandwidth pipes.

Many Web sites, especially gambling and pornography sites, which make tens of thousands to millions of dollars a day from online customers, have been extorted by cyber criminals to pay up to $100,000 to avoid getting a targeted DoS attack. These Web sites find it cheaper to pay the ransom than to lose the business that would result from the DoS. While many security companies are developing better anti-DoS capabilities to protect popular Web sites, the default anonymous nature of the Internet makes stopping DoS attacks difficult. Microsoft has responded by intentionally hardening the Windows TCP/IP network stack against specific types of DoS attacks, improving IIS's performance under heavy loads, and in setting performance thresholds.

Password Guessing Attacks

Many web servers are compromised because the administrators configure them with weak passwords. Most web servers contain either HTML-enabled logon screens or remote admin consoles. Attackers can often guess against these logon prompts using automated password guessing tools (such as Hydra) or by using manual methods. Even moderately complex passwords (for example, eight characters with multiple character sets) can be guessed by an attacker given enough time. Unfortunately, many web administrators don't even attempt to use long or complex passwords, so guessing the correct admin password doesn't take a significant amount of effort.

A great discussion of web server vulnerabilities is maintained at Open Web Application Security Project (OWASP) at http://www.owasp.org. Their top ten web server security errors list (http://www.owasp.org/index.php/OWASP_Top_Ten_Project) is a great list to review. While the list is terrific, it's depressing to see that the list hasn't changed much over the years, and it appears we are no closer to better securing web servers than we were in January 2003 (when the OWASP top ten list was first released). The next two sections will introduce IIS in general and then discuss the new features of IIS 7.


Introduction to IIS

IIS is an application providing many network services, including World Wide Web (WWW) publishing, File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP), Web Authoring Distributing and Versioning (WebDAV), Simple Mail Transfer Protocol (SMTP) virtual service, a web services platform, and many other applications and functionalities. It natively supports many languages and protocols, including HTTP, HTTPS, HTML, VBScript, JScript, ASP, and ASP.NET protocols and languages. Its default functionality can be extended using modules, .NET, ISAPI programs, handler programs, scripting, controls, SMTP, and more.

IIS was originally only installed on Microsoft's file server products, but starting with Windows 2000, was also available for enterprise workstation clients (for example, Vista Ultimate edition). IIS is not installed by default with Windows Vista, but can be installed or activated with minimal effort. When installed and activated, IIS installs with a bare minimum of services unless otherwise configured.

Note

In the past, IIS was not available on Home editions of Microsoft Windows, but IIS 7 is available on Windows Vista Home Premium Edition.

Table 9-1 shows popular IIS versions and their default operating systems.

Table 9-1: IIS Versions and Platforms Open table as spreadsheet
IIS VERSION | DEFAULT OS
4.0 | Windows NT 4.0 Server (NT 4.0 Workstation ran the Personal Web Server application)
5.0 | Windows 2000 Server or Workstation
5.1 | Windows XP Professional
6.0 | Windows Server 2003 and XP Pro 64-bit version
7.0 | Windows Vista/Longhorn


New IIS Features

IIS 7 builds upon IIS 6's excellent performance and security record, adding sweeping changes inside and out. The major new IIS 7 features include:

  • Granular, modular design and components

  • Reduced default install footprint

  • Replaced metadata config file with XML

  • New Admin tools

  • New troubleshooting and diagnostic tools

  • Integrated URL string filtering (you no longer need URLScan)

  • Hidden namespaces (you can hide folders from being accessed)

  • New authentication methods

  • Integrated form-based authentication

  • Authentication can be redirected to external sources (for example, SQL, Oracle)

  • Integrated ASP.NET and IIS authentication

  • Microsoft passport authentication is removed

  • Easier for Web site to run directly using worker process identity

  • Per Web site or application admin delegation

  • IUSR_computername (i.e., the IIS anonymous account) is deprecated, although it is now a built-in account with a well-known SID

  • IIS_IUSRS is a new built-in IIS group with a well-known SID for anonymous connections

  • IIS_WPG group is deprecated (although it will still appear on many installations)

  • Many new additional security features

These new features will be covered in more detail in the material that follows.


Installing IIS 7

To install IIS 7, it must be manually added from the Control Panel using the Programs and Features applet, selecting Turn Windows features on or off, and selecting the appropriate components under Internet Information Service (see Figure 9-3).

Image from book
Figure 9-3: Installing IIS Features


IIS Components

There are over three dozen components and subcomponents to choose from when installing IIS. Table 9-2 discusses the various components. One of IIS 7's biggest improvements over previous versions is the granularity of the features that can be, or not be, installed. For instance, you can install Windows Authentication, but not Digest Authentication. If you don't install a particular component, like Digest Authentication, the associated programming coding is not installed or kept in memory. This decreases the potential security vector attack points and provides incremental performance benefits. Installers should choose the bare minimum number of components necessary to support their web server's applications. Unfortunately, the new level of granularity makes installing IIS a chore. You can choose between 48 different feature checkboxes over three levels. There is no "install all" setting. To get a complete IIS install takes 24 separate enabled checkboxes. Of course, you should only install the bare minimum requirements necessary to meet your web application needs. Use Table 9-2 as a guide.

Table 9-2: IIS Components Open table as spreadsheet
COMPONENT | DESCRIPTION
FTP Publishing Services | Parent-category heading for File Transfer Protocol (FTP) service.
FTP Management Console | FTP Microsoft Management console snap-in. Should be selected if FTP service is enabled. Can be used to manage local and remote FTP servers.
FTP Server | File Transfer Protocol service. Enable if you want Vista to support FTP services.
Web Management Tools | Parent-category heading for IIS management tools, consoles, and scripts.
IIS 6 Management Compatibility | Sub-category heading to install IIS 6–compatible tools and APIs to manage IIS 7 services.
IIS 6 Management Console | Enable if you want to administrate remote IIS 6 services, including World Wide Web and FTP. It can also be used to administrate FTP on IIS 7 servers.
IIS 6 Scripting Tools | Installs IIS 6 configuration scripts.
IIS 6 WMI Compatibility | Installs IIS 6–compatible Windows Management Instrumentation (WMI) interfaces, allowing many local and remote IIS 6 management tools to operate.
IIS Metabase and IIS 6 configuration compatibility | IIS 7 does not use Metabase database files natively, as IIS 6 does. If this component is installed, Metabase compatibility APIs will be installed to allow legacy Metabase tools to be utilized on IIS 7 services.
IIS Management Console | New Microsoft management console snap-in for local and remote IIS 7 services.
IIS Management Scripts and Tools | If enabled, installs new management scripts and tools for local IIS 7 servers.
IIS Management Services | Installs web management interface to allow remote management using an Internet browser.
World Wide Web Services | Parent category for WWW services. Must be enabled if World Wide Web (WWW) services are desired.
Application Development Features | Child category for application development options.
.NET Extensibility | If enabled, will allow IIS WWW services to support .NET Framework applications. Needed for IIS 7's new protocol listeners (covered later).
ASP | If enabled, supports legacy Active Server Pages (ASP). High risk, should be disabled if not used.
ASP.NET | If enabled, will allow IIS WWW services to support ASP.NET Framework applications. High risk, should remain disabled if not used.
CGI | Enables a Common Gateway Interface subsystem to support CGI programs and scripts. High risk, should remain disabled if not used.
ISAPI Extensions | Allows ISAPI programs to respond for particular request types. High risk, should remain disabled if not used.
ISAPI Filters | Allows ISAPI filters (often DLLs) to filter and respond for particular types of requests. High risk, should remain disabled if not used.
Server-Side Includes | If enabled, implements server side includes, handling requests for documents ending in .stm, .shtm, or .shtml. Should be disabled if your web server does not use server-side includes.
Common Http Features | Child category. Needed for ASP.NET and other types of HTTP functionality.
Default Document | If enabled, will serve up defined default documents, such as index.htm or default.aspx, if the http request does not include a specific trailing document name.
Directory Browsing | If enabled on a web folder, will disable the standard HTTP rendering format and display all folder documents and files in a column list (much like a user might see on an FTP site). The user can then see the individual files and download them. Should not be enabled on most web sites, unless desired.
HTTP Errors | If enabled, will implement IIS's default error responses. Error responses have been used in the past to enumerate Web sites and to identify the existence of documents and filenames. Administrators can choose not to implement the default error documents and create their own customized error responses.
HTTP Redirection | If enabled, can allow HTTP requests to be redirected to other locations. Has been used maliciously in the past by spammers and other rogue hackers. Should be left disabled unless needed.
Static Content | Supports HTML content. Read-only static content is normally low risk. Most web servers will need this option enabled.
Health and Diagnostics | Child-category, if enabled installs tools to monitor and manage server and Web site performance and response.
Custom Logging | Enables custom logging interfaces.
HTTP Logging | Enabled by default. Monitors HTTP requests and responses.
Logging Tools | Installs IIS 7 logging tools and scripts.
ODBC Logging | Installs ODBC database interface capabilities.
Request Monitor | Enables requests to be monitored. Enabled by default.
Tracing | Enables additional troubleshooting capabilities for ASP.NET applications.
Performance Features | Child category for two performance-enhancing capabilities.
Http Compression Dynamic | For standard HTTP traffic compression; on dynamic content needed for ASP support.
Static Content Compression | Enabled by default. For standard HTTP traffic compression of static content.
Security | Parent category, allows administrator to enable various security and authentication mechanisms.
Basic Authentication | If enabled, allows local or domain authentication credentials to be passed in near clear-text format. Only needed for clients that cannot support more secure authentication methods (discussed more later). Should be disabled if not needed, unless all basic authentication is carried out over a secured connection, such as SSL/TLS or IPsec.
Client Certificate Mapping Authentication | If enabled, allows SSL or TLS client certificates to be used to authenticate Active Directory computer or user accounts.
Digest Authentication | If enabled, allows local or domain authentication credentials to be passed in a cryptographic hash format.
IIS Client Certificate Mapping Authentication | Maps client certificates to a one-to-one or many-to-one computer or user account.
IP Security | Enables administrators to restrict requests based on IP addresses or domain names.
Request Filtering | Enabled by default. Allows incoming URL requests to be filtered for legitimacy. Must be enabled to get functionality similar to legacy versions of URLScan (which no longer needs to be installed).
URL Authorization | Integrated authentication method. Allows authentication to be determined by a web application. Was previously available in IIS 6 using ASP.NET.
Windows Authentication | If enabled, allows local or domain authentication credentials to be passed in a very secure challenge-response format-LAN Manager, NTLM, or Kerberos. In order to be used, web server must be contactable using RPC or NetBIOS methods. Typically used for domain computers to intranet web servers. Doesn't typically work through external firewalls or over the Internet (without the use of a VPN or other configured methods). Discussed more later in the chapter.

When IIS 7 is installed on Vista, the following components are installed by default if no specific components are selected:

  • IIS Management Console, default document

  • Directory browsing

  • HTTP errors

  • Static content

  • HTTP logging

  • Request Monitor

  • Static content compression

  • Request filtering

The default IIS 7 install will allow only static content to be delivered. All active scripting is disabled by default. IIS 7 can support multiple Web and FTP sites and, unlike previous workstation versions, can do so at the same time. Each separate Web or FTP Web site must be bound to a separate TCP port number, IP address, or host header name (which is identical to the existing behaviors in server versions of IIS). IIS 7 can support multiple Web and FTP site configurations. IIS application files are located in a folder called %windir%\system32\inetsrv. The initial IIS 7 install creates a default Web site called, not surprisingly, the default Web site. Files for the default Web site are stored in \Inetpub\wwwroot by default, and contain only a single static web page (see Figure 9-4) that, if clicked will redirect the user to http://www.iis.net, Microsoft's official IIS support Web site.

Image from book
Figure 9-4: Default IIS Web site

Enabling IIS activates a handful of new executables and one or more services. The core executeables will all run in Session 0 using the Local System account. Interfaces (for example, InetMgr.exe) typically run in additional sessions (for example, Session 1) under the local user's security context. The main IIS WWW service is called the World Wide Web Publishing Service service. The service is launched in a Svchost process called IISsvcs. The IIS Worker Process (W3wp.exe) will also be launched.

When IIS is active, the web server will listen only on port 80 until otherwise configured. IIS runs using a multitude of files and processes. The main IIS process of Inetinfo.exe, running in the Local System context, is always present, but several other processes assist. Some such as Dllhost.exe may appear and then disappear, until later needed. It's important to note that in IIS 6 and above, no user code runs in these highly privileged processes.

Note

If Vista Home Basic is upgraded to Business or Ultimate editions, several IIS 7 features are installed and enabled by default. See http://www.support.microsoft.com/kb/930902/en-us for more details.


IIS Protocol Listeners

A protocol listener is a software routine that listens on a predefined communication channel (and port), and passes transmitted data (called messages) to and from the participating server service and communicating client. IIS 7 includes five default protocol listeners: Http.sys, Net.tcp, Net.pipe, Net.p2p and Net.msmq; and additional custom listeners can be created and used. IIS 6 had only one-Http.sys. The other new protocol listeners support Microsoft's new Windows Communication Foundation web services. With the exception of Http.sys, the other listeners require .NET Framework installation and the Windows Process Activation Service (WAS), which runs in the same Svchost process as the WWW service. However, protocol listeners can be implemented using WAS and not require IIS.

Each listener runs in kernel mode, directly interacting with the operating system. Microsoft has thoroughly tested each protocol listener for security vulnerabilities, trying their best to ensure they are not susceptible to buffer overflows and other common security mistakes. Although finding every security vulnerability is almost impossible, Microsoft successfully defended IIS 6's Http.sys against every attacker for over 4 years, so they have a leading example to follow. Protocol listeners can be activated in an XML configuration file called ApplicationHost.config. To minimize possible attack vectors, only the protocol listeners needed should be activated. The follow sections summarize each protocol listener.

HTTP.SYS

When IIS 7 is installed and active, the Http.sys kernel mode driver installs as the default HTTP protocol stack listener and intercepts and caches incoming HTTP requests. It also provides caching, logging, quality of service, and bandwidth throttling for the web server. Every active Web site registers itself with the HTTP protocol stack. The Http.sys driver includes built-in support for HTTPS, SSL, and TLS, instead of requiring a separate service (i.e., HTTP SSL), as was the case in IIS 6.

Net.TCP

Net.Tcp is a protocol listener supporting a new feature called Net.TCPPort Sharing, a part of the Windows Communication Foundation (WCF). Like Http.sys, it allows multiple applications to share a single TCP network port. Http.sys relies on the HTTP protocol, whereas Net.Tcp can be used with any protocol over any TCP port, and with any application. Not enabled by default, the Net.Tcp Port Sharing service accepts inbound connections using the net.tcp protocol and forwards them to their destination application. URLs utilizing Net.Tcp will look something like net.tcp://x.x.x.x/default.aspx, and will always use the TCP protocol. The Net.Tcp Port Sharing Service service must be started for this protocol listener to work. The Net.Tcp Listener Adapter service must be enabled for the Net.Tcp listener to be able to forward to WAS.

Net.Pipe

The Net.Pipe protocol listener relies upon the Named Pipes protocol, which has long been a part of Microsoft Windows. The best short explanation of Named Pipes is that it is a file sharing and communication protocol for applications, much like NetBIOS/SMB is for users. Behind the scenes of many Windows applications, Net Pipes is used to communicate between different processes. Now Named Pipes can be used to interact with IIS and WAS, although it is reserved for local inter-process communications. The URL moniker for the Net.Pipe protocol listener is net.pipe://. The Net.Pipe Listener Adapter service must be active in order to use Net.Pipe services.

Net.P2P

Peer-to-Peer (P2P) services were originally added to Windows XP Pro SP1 and later Windows operating systems. Windows Vista offers up new native P2P services and networking transports. The Net.P2P protocol listener can be used by clients by utilizing the URL moniker for the Net.P2P protocol listener of net.p2p:// (for more information, see http://www.msdn2.microsoft.com/en-gb/library/system.servicemodel.netpeertcpbinding.scheme.aspx).

Net.MSMQ

The Net.MSMQ protocol listener is useful for advanced applications requiring message queuing. Microsoft Windows includes a robust message queue handling service, which helps triage large amounts of incoming data and to ensure the completeness of complex transactions. Developers can create their own custom message queuing protocol listeners as well. Custom MSMQ protocol listeners normally have the name of msmq.<customname>. The URL moniker for the Net.Msmq protocol listener is net.msmq://. The Net.Msmq Listener Adapter service must be started in order for the Net.MSMQ protocol listener or any msmq customer listeners to be able to pass traffic to WAS.


Worker Processes, Application Pools, and Identities

IIS uses a combination of mechanisms to pull off what appears to be simple web hosting. It is essential that computer security workers understand the various parts behind the scenes of IIS in order to secure it.

Worker Processes

IIS protocol listeners forward client requests to the associated Web site's worker process. In IIS 7.0, Windows Activation Service (WAS) manages application pool configuration and worker processes instead of WWW Service. The worker process is user mode-based code that does the actual handling, delivery, and response to the incoming request for a particular Web site. For example, a worker process may retrieve HTTP content and send it to the requesting client, call an ISAPI filter to handle a particular type of request, or run a scripting engine.

Application Pools

Each Web site runs in an application pool, which is a named worker process and logical memory allocation where one or more Web sites or applications reside. Application pools can be shared by Web sites and applications or used to isolate sites and applications from each other (more on this in the "Defending IIS" section later in this chapter).

When IIS 7 is installed, two application pools, called the DefaultAppPool and Classic .NET AppPool, are created (see Figure 9-5). IIS 6 did not have the latter application pool, but Classic .NET AppPool behaves in the same way as IIS 6's DefaultAppPool. Application pools can be configured to run with or without (i.e., no managed code) .NET Framework (see Figure 9-6). The Managed pipeline mode refers to whether the developer wants ASP.NET and non-ASP.NET requests to be processed together (i.e., Integrated), which is a new IIS 7 feature, or separately (i.e., Classic) using Aspnet_isapi.dll for the ASP.NET requests.

Image from book
Figure 9-5: Default IIS application pools
Image from book
Figure 9-6: Choosing between managed and unmanaged environments

Additional application pools can easily be created, and each Web site and directory can belong to one or more application pools. Additional application pools can be created in IIS Manager by clicking the Add Application Pools option under Application Pools leaf object. Additional application pools can also be created using the command line as well. Here is the command and syntax:

     appcmd add apppool /name:string /managedRuntimeVersion:.string   Image from book
     /managedPipelineMode: Integrated | Classic

Placing different Web sites in different application pools isolates what corruption or damage can be done by one site to another. A web server administrator can run high-risk applications in their own application pool, separate from the main Web site. If a malicious action happens to a Web site in one application pool, the vulnerability does not immediately compromise Web sites in other application pools.

Note

When discussing how IIS works, application pools are often discussed as if they are the same as worker processes, even though they are not one and the same.

In IIS 7's default mode (called worker process isolation) there is a separate worker process for each application pool. Each runs in the W3wp.exe process, which runs in the Network Service security context by default. In previous IIS versions (or a Web site running in IIS 5 isolation mode), Dllhost.exe is the default single instance worker process for all Web sites. Applications and Web sites running in Low Application Protection mode (for example, ASP) use the Inetinfo.exe worker process, which as stated previously, runs in the Local System security context. This means that in previous versions of IIS, a single compromise could allow easy access to all Web sites on the server.

Note

The W3wp.exe process will not launch until a Web site on the web server is first accessed.
Note

In Vista, just as in previous Windows versions, Dllhost.exe can also be used by other applications, many of which are unaffiliated with IIS, so don't be surprised if you see it as an active process in memory.

Application Pool Identities

Each worker process and associated application pool runs in the security context of an application pool identity. The identity is a user or service account used to run the worker process and application pool (i.e., the security context that the worker process and application pool run in). The default identity for both default application pools is Network Service.

Introduced in XP Pro, the Network Service account has permissions similar to the Authenticated Users group, but accesses network resources using the web server's computer account. The Network Service account has the following privileges:

  • Replace a process-level token

  • Adjust memory quotas for a process

  • Generate security audits

  • Bypass traverse checking

  • Access this computer from the network

  • Logon as a batch job

  • Logon as a service

  • Impersonate a client after authentication

You can choose the more secure Local Service account if your application pool does not need to access other network services or computers. The Local Service account, also introduced in XP Pro, has permissions similar to the Authenticated Users group, but accesses any network resources using an anonymous null session because it does not have the "Impersonate a client after authentication" privilege. In XP Pro and above, network resources cannot be accessed using a null session, except to domain controllers. The Local Service account has the following privileges:

  • Replace a process-level token

  • Adjust memory quotas for a process

  • Generate security audits

  • Bypass traverse checking

  • Access this computer from the network

  • Logon as a batch job

If a Web site doesn't need access to other network resources (i.e., besides the normal remote requesting clients), the Web site administrator can change the worker process identity to Local Service.

Image from book
WHY DO APPLICATION POOL IDENTITIES RUN AS NETWORK SERVICE?

Many IIS security experts wonder why Microsoft, in the spirit of stronger security, did not default IIS application pool identities to the lower privileged Local Service account instead of Network Service. Although Microsoft has never officially answered this question, most observers feel the decision must have been made so that common legitimate applications were not broken when run on IIS 7. If IIS 7 broke a large percentage of the applications that were run on it because the default security settings were too secure, web developers might go to easier, less secure, competing products.

Image from book

You can create or use a custom user or service account (i.e., Specific User) for the application pool identity (see Figure 9-7). The pool will then have access only to the resources and permissions of the custom identity account. If you create a custom identity account, add it to the IIS_IUSRS group, which assigns the necessary permissions and privileges to allow the account to function as an IIS application pool identity. You then need to add the other NTFS file and folder permissions to the resources used by the web application.

Image from book
Figure 9-7: Setting a custom application pool identity

You can also choose the LocalSystem account for the identity if the application pool needs Administrator-level privileges and permissions. This is not recommended unless absolutely needed. If a hacker is successful in compromising a web application running in an application pool with the LocalSystem identity, he or she has far more potential to be damaging than if the application pool ran under Local Service or Network Service.

Note

In IIS 6, any application pool identity had to be added to a group called IIS_WPG to get the correct permissions. This group and requirement has been replaced by IIS IUSRS, although the previous group may still appear.

If the Web site using a custom application pool identity is also involved in delegation to another back-end server (for example, IIS front end authenticating users for an MS-SQL back-end database), a Service Principal Name (SPN) must be created for the custom identity. Specifically, the administrator can use Microsoft's SetSPN.exe utility (http://www.technet2.microsoft.com/WindowsServer/en/library/1033.mspx) to create the new SPN. The syntax would be similar to this for a Web site located at http://www.example.com using a custom user identity called custom in a domain called Contoso:

     setspn.exe -A HTTP/www.example.com contoso\custom


IUSR and IIS_USRS

When a user connects to an IIS Web site, the files and content are accessed by IIS in the context of an impersonated user. Whatever permissions and privileges the impersonated user has, so too does the connecting Web site user. This is an extremely important point to remember when configuring IIS security. IIS allows authenticated and anonymous connections. Authenticated connections must use a valid SAM or Active Directory security principal account, or any one of those additional authentication types added in IIS 7, one mapped to an external source, such as SQL, Oracle, and so on.

When IIS 7 is installed, a default user account is created called IUSR _<computername>, where <computername> is the name of the computer where IIS is installed along with a new group called IIS_IUSRS. In the past, IUSR_<computername> was the service account associated with any anonymous connection to the World Wide Web or FTP services. In IIS 7, the IUSR_<computername> account is deprecated. It has no default permissions and is included for backward-compatibility purposes only.

Any user or service account belonging to the IIS_IUSRS group (there are no default members) can now be used as the IIS anonymous account. By default, the IIS_IUSRS group has only Read & Execute permissions to the \Inetpub\ wwwroot folder. Any authenticated user, by default, has Read & Execute permissions to \Inetpub and \Inetpub\wwwroot. Additional NTFS permissions can be given to both anonymous and authenticated user accounts.

Both IUSR_computername and IIS_IUSRS are built-in accounts with "well-known" security identifiers (SIDS), much like Administrator and Administrators. This is new for IIS 7 and it allows Web sites and content to be copied or moved to other servers, and for the permissions this user and group had to remain. In the past, the user and group permissions had to be re-set any time the web server content was moved to a new server because new SIDs were referenced.

To recap, IIS 7.0 runs using a combination of one or more worker processes (W3wp.exe), and one or more protocol listeners, applications pools, or identities-all slave to the permissions granted to them for the related Web site content.

Figure 9-8 shows a theoretical example of IIS running three Web sites within two application pools, one using HTTP, the other using Named Pipes. An additional application is running using Net.tcp using WAS. Users accessing a particular Web site run its files in the context of an impersonated user, either by specifically authenticating or by indirectly using an IIS anonymous user account that is part of the IIS_IUSRS group (not to be confused with the completely unrelated anonymous null session built-in account).

Image from book
Figure 9-8: Example of IIS 7 running multiple web applications, with a range of components


IIS Administration

Every aspect of IIS can be managed using command-line tools, and nearly as much with a completely revamped and improved IIS Manager GUI (see Figure 9-9). It separates the various aspects of web server administration into different categories (for example, IIS, ASP.NET, Web Server Management, Server Components, Security, Performance, Health, and so on).

Image from book
Figure 9-9: IIS Manager

Previous versions of IIS stored most settings in a proprietary file called the Metabase. It was difficult to edit, and even more difficult to transfer to other servers. In IIS 7, configuration settings are stored in two new XML files. The Application.Host.config file (located in %Windir%\System32\inetsrv\ config) stores IIS server settings and each Web site has its own Web.config file for site-specific settings. Developers can literally copy these files to other IIS servers to create duplicate Web sites, or start with a cloned-based copy.

IIS administrators can also use Remote Desktop or another third-party remote control tool (PC Anywhere, VNC, and so on). Remote Desktop uses the Remote Desktop Protocol (RDP) over TCP port 3389 to provide a reliable and encrypted communications session.

Note

The RDP client should be RDP client version 6.1 or later, which corrects an authentication problem that previously allowed man-in-the-middle attackers to read encrypted communications.

RDP and many other remote admin tools allow complete control of the web server, and not just IIS. Whatever remote admin tool is used, the administrator should take great pains to make sure the application, password, and connection port are secure.

Feature Delegation

One of the biggest past criticisms of IIS was that it was difficult to give an IIS developer the permissions and privileges he needed to manage the Web site, without giving him control over the entire server. Or it was difficult to configure IIS so that one user had complete control over her Web site, and did not have control on other Web sites located on the same IIS server.

IIS 7 solves this problem with Feature Delegation and Administrator Lists. Unfortunately, Vista contains only the first feature, which is only half the solution. Using Feature Delegation, web administrators can set what features are modifiable on a web server basis (this should be expanded to be configurable on a per Web site or per application basis in future IIS versions). It is standard in the Windows environment that the delegation set for parent objects is inherited by child objects. Longhorn server will contain the Administrator Lists, which will then allow each allowed or denied feature set to be tied to a particular user or group. For now, Vista users will have to be happy with Feature Delegation by itself.

To use Feature Delegation, the user must be an Administrator for the parent object being delegated (i.e., Administrator for server or web administrator for Web site or application pool). The administrator does the following:

  1. Open up the IIS Manager console in Features View.

  2. Click the web server leaf object.

  3. Double-click the Feature Delegation icon under the Management pane (see Figure 9-10).

    Image from book
    Figure 9-10: IIS Manager with feature delegation option selected

  4. Choose the feature you wish to delegate (see Figure 9-11) and its default delegation state.

    Image from book
    Figure 9-11: Choosing the default delegation state

Each feature can then be set to one of four states:

  • Read Only (or Configuration Read Only)

  • Read/Write (or Configuration Read/Write)

  • Remove Delegation

  • Reset to Inherited

If a feature or configuration item is set to Read Only, it cannot be modified. If a feature or configuration option is set to Read/Write, it can be modified. Remove Delegation removes any specifically set previous delegation. Reset to Inherited lets the parent object's settings follow down into the child object for that feature.

The Feature Delegation affects only what can or can't be set using the IIS Manager GUI. The users wishing to read or modify the web server, Web site, or application pool must also have the desired NTFS permissions on the ApplicationHost.config file (for the web server) and/or Web.config (for the related Web site).


IIS Authentication

When a client machine connects to an IIS server, it will almost always connect as either an anonymous user (i.e., no user credentials supplied) or with supplied user account credentials. In IIS, user credentials can be stored in Active Directory or the local SAM, handled by an application, or stored in an external authentication database source. IIS allows seven different kinds of default authentication:

  • Anonymous

  • ASP.NET Impersonation

  • Basic Authentication

  • Digest Authentication

  • Forms Authentication

  • Windows Authentication

  • SSL/TLS Client Side Mapping (IIS and Active Directory)

Authentication methods can be configured in the IIS Admin tool by choosing the Authentication icon under the IIS pane (see Figure 9-12). One or more authentication methods can be selected per Web site, per folder, or per file (see Figure 9-13). For example, an administrator can allow anonymous connections to most of their Web site content, but require authenticated access to a particular folder or file. Disable or remove unused authentication methods.

Image from book
Figure 9-12: Configuring IIS Authentication option
Image from book
Figure 9-13: Choosing IIS Authentication method
Note

If anonymous and other authenticated methods are allowed at the same time, most browsers will try the anonymous connection first.

Anonymous Authentication

When a browser connects to IIS without supplying user credentials, which is often the case when a browser connects to a public Web site, IIS allows the user to access the Web site with the permissions assigned to the related IIS anonymous user account. Any account intended to be used as an IIS anonymous account should be in the IIS_IUSRS group.

Membership in the IIS_IUSRS group gives contained accounts Read and Execute permissions to \Inetpub\wwwroot, the default Web site location. If the referenced Web site is not located there, the anonymous account or the IIS_IUSRS group will need to be given the necessary permissions to the referenced content locations.

A new important change in IIS 7 is that anonymous web content can now be more easily run in the context of the site's application pool identity instead of the anonymous user. This could be accomplished in IIS 6 as well, but required more steps. Figure 9-14 shows the application pool and its identity being used instead of the defined anonymous user account.

Image from book
Figure 9-14: Enabling Web Application pool identity instead of IIS Anonymous User

ASP.NET Impersonation

ASP.NET Impersonation allows a developer to run their ASP.NET application in the security context of an authenticated Active Directory or local account user, or as another specific user (see Figure 9-15). ASP.NET Impersonation is disabled by default, and if enabled, defaults to the authenticated user option.

Image from book
Figure 9-15: Configuring the ASP.NET Impersonation setting

Basic Authentication

Basic Authentication is an older but widely supported HTTP standard that allows the user to log on using a SAM or Active Directory account. The user is prompted to input his or her logon name and password, and the browser encodes the information using Base64 encoding and transmits it to the server. Although Base64 encoding is not plain-text, it is near enough, and extremely easy to decode back to its plain-text original. Basic Authentication should not be used except in cases where backward compatibility is needed. You can enable Basic Authentication for compatibility reasons and use SSL/TLS (or another protective tunnel such as IPsec) to strongly protect the authentication stream.

Digest Authentication

Digest Authentication allows remote clients to use Active Directory user accounts to authenticate if the web server is a member of an Active Directory domain. The server must use Windows 2000 and IIS 5 or above and the client must be IE 5.0 or above. The user's account must also have the "Store passwords using reversible encryption" option enabled. When enabled, clients can authenticate using their normal user account, and the authentication transaction does not transmit the users in plain-text (unlike Basic Authentication).

Note

If Digest Authentication is used on a Windows Server 2003 web server running in a Windows 2003 domain, Digest Authentication can become Advanced Digest Authentication (using more secure MD5 hashes).

Forms Authentication

Forms authentication is a new IIS 7 logon feature that can be installed on a web page by including a file called Login.aspx or its related code into an existing web page. When a user connects to a referenced document, it presents them with a login name and password prompt screen that will then pass the credentials from IIS to an external authentication database, such as Microsoft SQL or Oracle, or to any installed security provider. You can do this with ASP.NET applications prior to IIS 6. However, in IIS 6, it works for ASP.NET content only. In IIS 7, it will work for all content.

Windows Authentication

Windows Authentication (formerly called Window Integrated Authentication or Integrated Windows Authentication) allows a client to connect using one of the normal Windows logon authentication methods (LM, NTLM, NTLMv2, or Kerberos). This method requires that the client and IIS server reside in the same domain, and for that reason Windows Authentication does not normally work over the Internet. NTLM and NTLMv2 can get past a firewall but are generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.

Windows Authentication is intended for internal intranet sites, where the user should not be bothered by being asked to re-authenticate when they connect to the intranet server. Any Web site in the user's intranet sites zone using Windows Authentication will not prompt the user for logon credentials unless the logon credentials are valid. The default option of whether to always be prompted or not is set under each security zone's settings in Internet Explorer (covered last chapter). The remaining authentication methods will always prompt the user for logon credentials and pass them to the web server.

Client Side Mapping

SSL/TLS Client Side Mapping is another potential default IIS authentication method. If SSL/TLS is enabled on a Web site, the Web site can also require that the client provide an authenticated SSL certificate, as well. The client's SSL/TLS certificate can be stored in Active Directory (i.e., mapped), so that when the Web site requests it, it can be retrieved from the user's Active Directory user object and handed to the server for validation. This is a very secure form of authentication but requires heavy initial and ongoing administrative use of a PKI infrastructure.

In previous versions of IIS, all of the authentication methods came as one default package. If IIS was installed, then all of these methods could be used. Only the anonymous user was enabled by default on the Default Web Site, but any authentication method could be turned on with a simple mouse click. In IIS 7, each individual authentication method can be enabled or disabled on a per module basis. For example, if the Web site doesn't use Basic Authentication, the administrator can remove the Basic Authentication module, and the code will not even be available in IIS for use or exploitation.

Table 9-3 summarizes the basics of each IIS authentication method.

Table 9-3: IIS Authentication Method Summary Open table as spreadsheet
METHOD | SECURITY LEVEL | HOW PASSWORDS ARE SENT | CROSSES PROXY SERVERS AND FIREWALLS | CLIENT REQUIREMENTS
Anonymous authentication | None | N/A | Yes | Any browser
ASP.NET Impersonation | Medium | Obscured | Yes | .NET
Basic authentication | Low | Base64 encoded clear text | Yes, but sending passwords across proxy server or firewall in clear text is a security risk because Base64 encoded clear text is not encrypted. | Most browsers
Digest authentication | Medium | Hashed | Yes | Internet Explorer 5 or later
FORMS Authentication | None | Plain-text | Yes | .NET
Windows authentication | High | Hashed when LM or NTLM is used; Kerberos ticket when Kerberos is used. | No, unless used over a VPN connection | Internet Explorer 2.0 or later for NTLM; Windows 2000 or later with Internet Explorer 5 or later for Kerberos
Certificate authentication | High | N/A | Yes, using an SSL connection | Internet Explorer and Netscape
Note

Windows Authentication provides significant protection as compared to Basic and Digest Authentication methods. However, like regular Windows logons, Windows Authentication can use either LM or NT password hashes and LM, NTLM, NTLMv2, or Kerberos authentication protocols. As discussed in previous chapters, LM password hashes and LM and NTLM authentication protocols, if used, can be cracked fairly easily. If Windows Authentication is going to be used, ensure that only NT password hashes are used, and that only NTLMv2 or Kerberos authentication protocols are used in the process.

Table 9-4 discusses the various advantages and disadvantages of the authentication protocols requiring logon credentials.

Table 9-4: Comparison of Authentication Methods Requiring Credentials Open table as spreadsheet
AUTHENTICATION METHOD | ADVANTAGES | DISADVANTAGES
Basic Authentication | Doesn't require IE or Active Directory. Supports authentication through firewalls and proxies. Can be used to authenticate local accounts. Stores hash of the user credentials in Active Directory. | Plain-text transmission of credentials. Low security. Consider using adjunct security tunnel, such as SSL, TLS, or IPsec if Basic Authentication is desired.
Windows Authentication | Protects user credentials. Provides high security. Requires IE 2.0 or later (5.0 and later for NTLMv2 and Kerberos authentication). | Requires Microsoft clients. Will not work across a proxy server. May use low-level encryption for LM depending on the specifics.
Digest Authentication | Protects user credentials. Provides medium security. | Requires Internet Explorer 5 or later.
Forms Authentication | Easy to set up logon authentication on any Web site; can be hooked to external authentication source. | Logon credentials not protected by default, should be used with SSL/TLS.
Client Certificates | For server authentication (certificates stored on the server), your organization obtains certificates from a trusted certification authority. For client authentication, map certificates to users' accounts stored in Active Directory running on Windows 2000 Server or later. Provides high security. | For client authentication (certificates stored on the clients), your organization has, or is willing to deploy, a public key infrastructure (PKI). For client authentication, you have a method of securely distributing the certificates to the clients.

It's also important to remember that most of the IIS logon authentication methods are more concerned with transmitting authentication credentials between the remote client to the server and are not as concerned with integrity and confidentiality issues. To ensure those latter points, use an adjunction protection tunnel such as SSL/TLS or IPsec.


Web Server Access Control Permissions

Two types of access control permissions apply to IIS: IIS Handler Permissions and NTFS. Handler permissions are specific to IIS and guide how various types of content are accessed. NTFS permissions are the ultimate deciding access control method, but IIS permissions also play an important role.

Note

Share permissions do not affect IIS web or FTP connections.

IIS Handler Permissions

Internally, IIS divides its own permissions into two subsets, Resource and Execution permissions. IIS has its own handler permissions that apply to each Web site, virtual directory, folder, and file, or to the web server as a whole. Permission applied to parent objects is inherited by the child objects unless more specific settings are applied to the child object. The IIS handler permissions are:

  • Read

  • Script

  • Execute

Read permissions allow a client to download a web page, view or download files, navigate folders, serve up default documents, or allow directory browsing. Read is the default permission for all Web sites, pages, files, and folders. If you disable this permission, static content cannot be displayed, although scripts, ISAPI filters, and other executables will still be active and able to render if they have the other appropriate permissions. Script permissions allow scripts (ASP, CGI, and so on) to run. If the user needs to see content returned by the script, you should also enable Read permissions. Execute permissions allow executable content (ISAPI filters, applications, DCOM objects, and so on) to be executed.

To set handler permissions, select the web server object you want to set the permission on in IIS Manager (Web site, folder, file, virtual directory, and so on), and then double-click the Handler Mappings icon under Features view (see Figure 9-16).

Image from book
Figure 9-16: Selecting Handler Mappings in the IIS Manager

Next, select Edit Handler Permissions in the Actions pane. Choose the appropriate permissions for the web server object selected (i.e., Read, Script, Execute) as shown in Figure 9-17.

Image from book
Figure 9-17: Choosing the appropriate Handler permission

You can double-click on each Handler Mapping (StaticFile, CGI-Exe, and so on) and choose whether the referenced handler handles files, folders, or both (see Figure 9-18).

Image from book
Figure 9-18: Choosing handler focus

You can also click the Verb tab and choose which HTTP verbs are valid when used against a particular handler and its related content (see Figure 9-18). This was a feature previously available only if you installed URLScan (http://www.microsoft.com/technet/security/tools/urlscan.mspx) or the IIS Lock-down Tool (http://www.microsoft.com/downloads/details.aspx?FamilyID=&DisplayLang=en) for legacy systems on IIS hosts. It is a very important, secure setting.

HTTP verbs, known as HTTP methods in RFC 2616 (http://www.tools.ietf.org/html/rfc2616), which defines the current HTTP 1.1 specification, determine whether users can request (GET) or write (PUT or POST) information to a Web site. Current HTTP verbs include:

  • GET

  • POST

  • HEAD

  • PUT

  • POST

  • OPTIONS

  • DELETE

  • TRACE

  • CONNECT

Note

Read RFC 2616 for more details on HTTP verbs and what they allow.

IIS allows you to specify which HTTP verbs are allowed to be used in a connection string (i.e., request) from a client (see Figure 9-19). Officially, per the RFC, GET and HEAD (which allow the client to request the server's identifying information) must be enabled on all Web sites to be RFC-compliant. Other verbs should be disabled unless needed.

Image from book
Figure 9-19: Configuring HTTP verbs

Three previous IIS permissions that some administrators may expect to be present are no longer available in the handler's permission configuration location. They are Write, Script Source Access, and Directory Browsing. Write is tied to WebDAV (along with Script Source Access), which has not yet been added to IIS 7. WebDAV will eventually be added back in as a separate module. Write permission access is now handled by the underlying NTFS permissions. Write allows the connecting user to upload and modify content. This permission should not be given unless writing and modifying content (via HTTP PUTor POST verbs, or WebDAV) are allowed. In some cases, write permissions may not be required when using a program specifically designed for this purpose, such as FrontPage Server Extensions or a custom application.

Script Source Access allows the client to read the web page's source code. This is normally okay, but you may want to disallow this if revealing the web page's source code or scripts can inadvertently reveal sensitive information (such as passwords).

Directory Browsing is now a separate feature available in the Features view in IIS (see Figure 9-20). The Directory browsing permission has always been a unique one. If selected, browser clients will not download and display HTML content as they normally would. Instead, if the specific document requested is not available, the directory is shown along with a listing of its contained files and folders (much like how an FTP directory might be displayed). Most Web sites normally do not have this permission enabled, and it is disabled by default in IIS 7. However, enabling directory browsing is a convenient way to allow users to view, upload, and download files. To enable Directory Browsing, select the web server object you want to allow Directory Browsing on (typically a Web site, folder, or virtual directory), and double-click on the Directory Browsing feature. Then click the Enable button in the Action pane. You can then modify the file attributes shown in the Directory Browsing window (see Figure 9-21). Directory Browsing is commonly enabled on intranet platforms and applications.

Image from book
Figure 9-20: The Directory Browsing Feature in IIS Admin
Image from book
Figure 9-21: Modifying Directory Browsing attributes

Administrators looking for an alternative to secure FTP, which has had trouble becoming a commonly supported standard, should consider using directory browsing instead. Secure FTP clients and servers that talk to one another without issues are hard to find. Instead, enable directory browsing on an HTTPS Web site containing the needed files and folders. Every user's browser will be able to connect and the content and authentication credentials will be authenticated and encrypted by default. Users will be able to right-click and Save As any file and they can drag-n-drop upload files (or save directly to the Web site using their local application if WebDAV is also enabled). Table 9-5 summarizes IIS permissions and their customary use.

Table 9-5: IIS Resource Permission Summary Open table as spreadsheet
PERMISSION | DESCRIPTION
Read | Users can view the content and properties of directories or files, and execute script content. This permission is set by default and is required for Web sites that have static content. If all of your content is scripted, such as a Web site that only uses ASP content, you can remove the Read permission, but this is not generally recommended as it may interfere with rendering static content that may be mixed with the Web site's application.
Write | Users can create, upload, modify, and delete content.
Script | Source Access Users can access source files and scripts. If the Read permission is set, then users can read source or script files; if the Write permission is set, then users can modify source or script files. Must have either the Read or Write permissions set to enable. Set this permission when using WebDAV. If enabled, make sure that you require authentication for this site and that your file permissions are set correctly.
Directory browsing | Users can view file lists and collections, and download files. Enable Write permissions, too, to allow file uploading.
Note

FTPS (FTP using SSL/TLS), along with other significantly improved FTP features, are arriving as a separate add-on for IIS 7 running on Longhorn. The new FTP features may be back ported to Vista.
Note

You can keep the Directory Browsing permission disabled, but allow Write permission to create a "blind drop" Web site, where users can drop off files.

NTFS Permissions

NTFS permissions play a huge role in IIS. Ultimately, if the connecting client "breaks out" of IIS, the NTFS permissions assigned to the web pool identity and impersonated user account are the security mechanism of last resort. All of this assumes you install IIS and the Web site content on an NTFS partition. And you should never install IIS on anything but an NTFS partition!

Web server content files are installed to \Inetpub\wwwroot by default. Default permissions are:

  • System and Administrator have full control.

  • Users group has Read & Execute.

  • IIS_IUSRS group has Read & Execute.

When creating any Web site, the NTFS permissions assigned should be the bare minimum needed by the connecting user, impersonated account, and web application pool identity to reflect the Web site accurately and thoroughly. Although this might seem confusing at first, the effective permission security of any IIS Web site is determined by the union of:

  • The NTFS permissions given to the application pool identity account.

  • The NTFS permissions given to the user account the client uses to authenticate to the web server (for example, anonymous or an authenticated user account).

  • The IIS permissions set on the Web site, virtual directory, folder, or file.

  • The IIS execute permissions set on the Web site, virtual directory, or folder.

Understanding the effective outcome of these permissions on each folder and file in each IIS Web site is essential to being a knowledgeable IIS administrator. Read only Web sites should be restricted by Read only NTFS permissions. If executable program files are not needed, the execution permissions should not be set to Scripts and Executables. Permissions are at the core of IIS security, but the features and functionality that IIS is running also play a huge part.


Defending IIS

IIS is secure by default out-of-the-box. But web servers are a combination of components (i.e., network environment, hardware, software, OS, and applications. Making sure IIS and its running applications are secure means checking and hardening a lot of components beyond IIS. This section of the chapter will cover system and IIS hardening recommendations.

Step Summary

Here are the summarized steps that need to be performed to strongly harden an IIS server:

  1. Configure network/perimeter security.

  2. Ensure physical security.

  3. Install updated hardware drivers.

  4. Install operating system.

  5. Configure host firewall.

  6. Configure remote administration.

  7. Install IIS.

  8. Install patches.

  9. Harden operating system.

  10. Configure and tighten IIS.

  11. Secure Web site(s).

  12. Clean and test.

  13. Install and tighten applications.

  14. Conduct penetration tests.

  15. Deploy.

  16. Monitor log files.

Intranet web servers or sites with reduced exposure risk may not need a web server hardened beyond the Microsoft defaults. IIS is very secure out-ofthe-box. However, following these recommended steps will result in a significantly harder-to-attack IIS web server and offer additional defense-in-depth responses if other parts of the web server or defense fail. Now, we'll cover each of those steps in detail.

Configuring Network/Perimeter Security

Before hardening IIS can even begin, an administrator must make sure the network that is installed is safe and secure. The network should be free of rogue software, malicious mobile code, and malicious network sniffers. Any perimeter firewalls or routers should allow only the bare minimum of TCP/IP ports to or from the server. In most cases, that means just allowing TCP port 80 and maybe 443 (for HTTPS) from the Internet to the server. If the web server serves up normal WWW traffic only, the perimeter filters should not allow any other port, except maybe the remote management port, to access the server.

No port traffic should be allowed from the web server to the Internet, by default, unless it is a part of the web server's function. Temporary exceptions may be made for port 80 traffic (for browsing the Web to get patch updates) and port 53 (for DNS queries). However, many Web sites have these ports open from the web server to the Internet all the time, and this is allowing too much access. If a hacker is successful in placing and executing a rogue program, and egress ports are allowed through the filter, the hacker may be able to send a command shell back from the server to his remote location over the open ports.

Ensuring Physical Security

The web server computer should be in a physically secure location. Unauthorized users should not have physical access to the computer. Consider buying a computer that allows physical access to be controlled by a physical mechanism (for example, lock or Smart card). The computer should have a locking case that prevents easy theft of the hard drive.

Unless otherwise contraindicated IIS should always be installed on a dedicated computer. Any IIS server invites increased hacking attempts and makes any computer it is installed on a higher risk of successful exploitation. And any other application may make IIS vulnerable to a side-channel attack.

Prevent booting from anything but the primary boot drive. This will prevent local attacks that attempt to circumvent regular Windows security mechanisms. It will also prevent boot viruses and other types of malware. Disable any unused USB, serial, and printer ports. Then password-protect the BIOS so that the configuration can be maintained. Use a BIOS password that is long and complex, but one that is not the same as your normal admin passwords.

Installing Updated Hardware Drivers

Don't forget to check for and install updated hardware drivers for your computer's BIOS, motherboard, interface cards, video card, and hard drive controller cards. It is the rare computer that arrives with all the drivers updated. It would be a shame for a web server to get exploited or for its data to become corrupt because the server's hard drive controller card had a bug.

Installing an Operating System

To prevent directory traversal attacks, IIS should be installed on a system with two separate, clean hard drives, each formatted with NTFS; or at least create two separate logical volumes. IIS has not been the victim of a directory traversal attack in many years, but in the event that a hacker develops a successful one, having the IIS server software and content installed on one hard drive and the Windows operating system installed on another will prevent future traversal attacks.

Install the Windows operating system as you normally would. Most web servers should be installed as standalone servers, unless the web server will be participating in domain authentications (for example, Windows Authentication). Unless you are dealing with an extranet server, most public facing web servers don't need Active Directory. If Active Directory is accessible through the web server (either because it is a domain member or domain controller), a successful hacker will be able to gather much more information. IIS should never be installed on a Domain Controller.

You want to install the OS with the minimal settings, with the minimal applications, and the minimal services loaded. If possible, load the OS with a static IP address. Dynamic IP addressing might give the hacker a way to exploit the server. Optimally, the web server would not be connected to the network until after all patches were installed.

Configuring a Host Firewall

As soon as the OS is installed, install a host-based firewall on the operating system. You want to protect the web server from remote exploitation. The built-in Windows Firewall is a good choice. It does a fine job at protecting Windows by preventing all inbound connections not initiated by an outbound connection, or by using rule exceptions.

Keep the firewall enabled with no port exceptions until OS and IIS patching have occurred. When the server is ready for operations, enable the firewall for only the port exceptions needed to run the web server. Often these exceptions would be ports 80, 443 (if HTTPS is needed), and a remote management port.

Configuring Remote Administration

While any remote admin tool (PC Anywhere, VNC, and so on) can be used, Remote Desktop is an excellent choice for remote administration on Windows computers. However, because web servers are high risk attack targets, risk can be minimized by making the changes described here.

First, make sure the latest RDP client, which has improved security and authentication, is being used. On the web server, change the default RDP port from TCP 3389 to another number that is random and high. By not running RDP on the default port, it makes it harder for remote attackers to detect and abuse RDP The web server's RDP listening port can be changed using a regedit modification to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ Terminal Server\WinStations\RDP-Tcp value. Change the value to decimal (versus hexadecimal) and input the new port. On the client-side, from which the remote admin is connecting, the RDP client connection string must include a port number at the end of the connection string to connect to indicate the non-default port number used (for example: http://www.example.com:33089). See http://www.support.microsoft.com/?id=187623 for more details.

There are other RDP changes you should make to the Terminal Services (which RDP uses) settings on the web server. Specifically deny access to IIS anonymous user accounts and the anonymous null session. This can be done by adding the related user accounts (or the IIS_IUSRS group) to the "Deny logon through Terminal Services" privilege in the Group Policy or the Local Computer Policy at \Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

Enable high-level encryption under \Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Encryption and Security\Set client connection encryption level. In the same area, enable "Delete temporary folders on exit, Use temporary folders per session," disable the Active Desktop, set the permission capability to Full Security, and restrict each user to one session.

Force the RDP users to close the session after disconnecting. These options are available in the Terminal Services Configuration console or in an Active Directory domain, under the remote admin user's Sessions tab in their User Account properties.

Enable "Do not allow an initial program to be launched. Always show desktop" in the Terminal Services Configuration console. In the console, disable all mappings except the clipboard under Client Settings.

Once these changes are made, RDP can be confidently used for remote administration of IIS web servers.

Installing IIS in a Minimal Configuration

Install IIS with the default options. IIS needs to be installed so patches can be applied against it. Many patching tools, including Windows Update, WSUS, and other Microsoft patching tools, require that the software they are patching be installed and active before the missing patches can be detected and applied. At the same time, installers need to minimize available attack vectors until after the patches are applied. After hardening the OS and installing patches, any additional IIS functionality needed can be installed.

Installing Patches

Install all OS and application patches, being sure to install service packs before other patches. This may be complicated by the fact that the server may not be connected to the network or a filtering device may be blocking access to Windows Update from the server (as previously recommended). Install as many patches as you can without connecting to the network. In most cases this means downloading OS and IIS patches from another already patched computer and then installing them manually on the server. If you must open port 80 to run Windows Update and download the patches from Microsoft, open only ports 80 and 53 outbound (if needed). Windows Firewall should automatically open the needed ports when needed. Run Windows Update or any other trusted patching tool, install the missing patches (or service packs), and then disconnect. Continue running the patching routine until no more patches are missing. It is not unusual for it to take two or three complete patching cycles.

Administrators may want to consider enabling the Automatic Updates service. If so, AU should download the patches, but never automatically install. Consider installing and using Microsoft Baseline Security Analyzer (MBSA) to check for any missing patches. If not connected to the Internet, you can download MBSA and the latest Mssecure.xml file from another patched machine and manually install and test. Delete any temporary folders used by the patches and reboot the server as required.

Hardening the Operating System

Now is the time to harden the underlying OS. You want to disable or remove any service or feature that is not needed to support the web server, its applications, or its administration. This section will discuss an example scenario demonstrating how to harden a standalone web server needing a bare minimum of services. Web servers with complex requirements (such as down-level client compatibility, domain membership, dynamic content, and so on) will not be able implement all suggestions.

A standalone web server facing the Internet and not needing domain authentication needs only the following services enabled:

  • Application Layer Gateway Service (if Windows Firewall is used)

  • Automatic Updates (if used)

  • Background Intelligent Transfer Service (if used)

  • Basic Filtering Engine

  • COM+ Event Service (if COM objects are used on server; when in doubt, leave enabled)

  • Computer Browser (only if needing to NetBIOS browse or connect to other computer's drives or printers)

  • Cryptographic Services

  • DCOM Server Process Launcher (if Distributed COM objects are used)

  • DHCP Client (if used)

  • DNS Client (if used)

  • Event Log

  • FTP Publishing Service (if used)

  • Group Policy Client (if used)

  • IIS Admin Service

  • IKE and AuthIP IPsec Keying Modules (if IPsec is enabled)

  • IPHelper (if IPv6 is used)

  • IPsec Policy Agent (if IPsec is enabled)

  • .NET Framework

  • .Net.Msmq Listener Adapters (if used)

  • .Net.Pipe Listener Adapters (if used)

  • .Net.Tcp Listener Adapters (if used)

  • .Net.Tcp Port Sharing Service (if used)

  • Net Logon (if authenticated remote domain logons are used)

  • Network Connections

  • Plug and Play

  • Protected Storage

  • Remote Procedure Call (RPC)

  • Security Accounts Manager

  • Terminal Services (if RDP is used)

  • Web Management Service (if remote features are used)

  • Windows Management Instrumentation (if WMI is used)

  • Windows Process Activation Service (WAS)

  • Windows Firewall (if used)

  • World Wide Publishing Service (of course)

Every service should be disabled unless explicitly needed. Uninstall or remove all other non-needed applications and services.

Use Local Computer Policy or Group Policy to obtain the following settings:

  • Set minimum password size to 14 (largest value possible right now).

  • Give 15-character passwords to all custom application pool identity and administrative accounts.

  • Enable password complexity.

  • Enable Account Lockouts (3–5 bad passwords in 1 minute, lock out for 1 minute).

  • Rename the Administrator and Guest accounts.

  • Remove the Everyone and Power Users groups from "Access this computer from the network" user right.

  • Under User Rights Assignment, remove Backup Operators as members of the "Access this computer from the network" user right (unless you do remote backup of the web server).

  • Change Unsigned Driver behavior from Warn to Don't Allow.

  • Enable Message Text for Interactive Logon (just to defeat any bruteforce logon tools).

  • Disable Logon caching.

  • Enable the "Do not allow the anonymous access of SAM accounts and shares" option (although this may disable some remote management tools).

  • Enable the "Do not allow the storage of credentials or Passports for network authentication" option.

  • Enable the "Do not store Lan Man hash value on next password change" option.

  • Change LM Authentication Level to NTLMv2, refuse LM and NTLM (unless you need down-level clients to authenticate using Integrated Windows authentication).

  • Enable the Clear virtual memory page file option (although this will cause long shutdown and bootup times, so measure use against availability concerns).

  • Remove Posix as an optional Windows subsystem.

  • Restrict CD-ROM and floppy drives use to local logged-on users only.

  • Deny Log On Locally right to all members of the IIS_IUSRS group.

  • Enable the "Interactive Logon: Do not display user info" option.

  • Remove DFS$ and COMCFG from file shares that allow anonymous logon.

  • Disable File and Printer Sharing in the Network Configuration dialog box.

Reboot the system and troubleshoot any resulting error messages.

Configuring and Tightening IIS

Now that the OS is hardened, let's turn our attention to IIS. Following are web server-specific changes to make (as compared to Web site changes).

Installing Additional IIS Features

Now is the time to choose which additional IIS features to install. The objective is to install features and modules necessary to support the Web site, and disable or minimize everything else. If features beyond static content are needed, follow the steps in the previous section, "Installing IIS 7," again and install the needed IIS components. Choose to install only the options necessary to make your Web site meet its operational requirements. Every additional feature is a potential attack point.

IIS 7 Modules

IIS 7 has broken down key functionality into dozens of task-specific DLL modules. These modules can be loaded and unloaded globally, per Web site, or per application. Remove unused modules. For example, if none of your Web sites will ever use SSL client certificate mapping, you can unload the Authmap.dll. Table 9-6 shows some of the security modules that can be loaded or unloaded.

Table 9-6: Sampling of IIS 7 Security Modules Open table as spreadsheet
MODULE NAME | DESCRIPTION | MODULE DLL
AnonymousAuthModule | Performs Anonymous authentication when no other authentication method succeeds. | Inetsrv\Authanon.dll
BasicAuthModule | Performs Basic authentication. | Inetsrv\Authbas.dll
CertificateMapping-AuthenticationModule | Performs Certificate Mapping authentication using Active Directory. | Inetsrv\Authcert.dll
DigestAuthModule | Performs Digest authentication. | Inetsrv\Authmd5.dll
IISCertificateMapping-AuthenticationModule | Performs Certificate Mapping authentication using IIS certificate configuration. | Inetsrv\Authmap.dll
RequestFilteringModule | Performs URLScan tasks such as configuring allowed verbs and file extensions, setting limits, and scanning for bad character sequences. | Inetsrv\Modrqflt.dll
UrlAuthorizationModule | Performs URL authorization. | Inetsrv\Urlauthz.dll
WindowsAuthModule | Performs NTLM integrated authentication. | Inetsrv\Authsspi.dll

This information is taken from http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis7/TechRef/.mspx.

You can enable and disable various modules by using the IIS Manager and clicking on the Modules icon (see Figure 9-22), and then adding and removing the various modules as desired (see Figure 9-23). Remove all modules not needed to support the Web site and application.

Image from book
Figure 9-22: Selecting Modules Feature in IIS 7
Image from book
Figure 9-23: Enabling or disabling specific modules in IIS 7

Minimizing Web Components Even Further

Minimize all web components to the bare minimum set needed. Disable and/or remove unneeded items, including the following:

  • Protocol listeners

  • IIS components

  • IIS handlers

  • IIS handler permissions

  • Authentication methods

  • Providers (which store session states)

  • Scripts, ISAPI filters, and so on

  • MIME types

  • IIS content

Most of these components are configurable in IIS Admin and by directly editing the XML config files. Most settings are configurable on a per web server, per Web site, and per web object basis (to varying degrees). Every component removed is one less attack vector to worry about; plus it saves on management and backup time.

Feature Delegation

Use feature delegation to minimize the number of web server administrators and what each web server administrator can do. Optimally, you would have only one user account able to administrate all Web sites on the server. That account would have a strong password, which was known only to a minimal set of administrators.

Strengthening NTFS Permissions

On dedicated web servers, remove NTFS permissions that are granted to the Everyone group on the root folder of disk volumes supporting web server content. Remove any compilers, development environments, or sample files.

Using Windows Explorer, set Full Control permission to Deny on the \%windir% and %windir%\System32 folders for the IIS_IUSR group. Then add Everyone Deny permissions to the Windows\Temporary Compressed Files, unless web compression is needed. Delete all files in the iisadmpwd folder, if it exists.

Note

Test this specific recommendation heavily before implementing. Some applications require access to the %Windir%, %Windir%\System32, and Temporary Compressed Files folders in order to function appropriately. Additionally, denying Everyone access could prevent other programs, such as antivirus scanners, from working correctly. Adding this specific deny recommendation is a great defense-in-depth step for many different types of attacks, but may cause operational issues. If in doubt, skip it or temporarily remove it in a troubleshooting scenario.

Configuring Request Filtering

Request Filtering (known as URL Filtering in previous versions of IIS) enables an administrator to define what request string traffic from client machines is and isn't allowed to be processed by their IIS server. Invalid connection traffic is simply dropped. In previous versions of IIS, a separate program called URLScan had to be added to gain full URL filtering capabilities. Now, the functionality is built into IIS 7, although at the moment it can be configured only by editing the web server or Web site XML configuration files directly. A great Request Filtering summary (and URLScan comparison) can be found at http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=1040. At a bare minimum, enable the following filter features:

  • Set UseAllowExtensions to 1. This will enable URL Filtering to deny-by-default any extension not specifically allowed. Then under the AllowedExtensions section, type in only the file extensions needed on the web server. Only content files being downloaded or uploaded need to be added. Be sure to add "." to AllowExtensions (just the period, not the quotes) to cover files that don't end in an extension.

  • Set MaxURL to 70 or some other number that indicates the maximum size of the URL string that your server will accept. You want to prevent overly long URLs, possibly containing buffer overflow or directory traversal attacks, from being uploaded.

  • Set MaxAllowContent Length to 100000 or something acceptable that indicates the maximum size of any single content component. Again, the idea is to prevent unauthorized uploading or downloading.

In URLScan, the Set AllowVerbs feature allowed the admin to determine what HTTP verbs were and weren't allowed to reach the web server. As discussed previously, this functionality has been moved in the Handler Permissions feature (and it can be added manually as well). Using IIS Admin it can be more easily configured on an even more granular basis.

For good security, allow only the GET and HEAD HTTP methods to reach read-only Web sites. Block all other methods. For Web sites that must allow users to modify content, additionally allow the PUT and/or POST methods, as required. The PUT verb is needed for regular HTTP write operations and the POST verb is need for writing done via HTML forms. Unless otherwise specifically needed, block all other verbs.

Here is an example of how an administrator would modify a Application-Host.config file to add Request Filtering:

     <configuration>
         <system.webServer>
             <security>
                 <requestFiltering>
                     <requestLimits>
                         maxAllowedContentLength="10000000"
                         maxUrl="200"
                         maxQueryString="35"
                     </requestLimits>
                     <denyUrlSequences>
                         <add sequence=".."/>
                     </denyUrlSequences>
                     <verbs>
                         allowUnlisted="false"
                        <add verb="GET" allowed="true" />
                    </verbs>
                 </requestFiltering>
             </security>
         </system.webServer>
     </configuration>

Securing Web Sites

Now that the overall web server is secured, the following settings should be made to each Web site:

Hardening NTFS Permissions

Do not install any Web sites to \Inetpub\wwwroot. That's where any hacker will look for web files. Instead, install to almost any other randomly created directory. Consider naming the directory something innocuous, like D:\Temp, if you want to fool any local hackers. Most hackers and web server scripts expect Web sites to be in the default locations, so use another directory name and fool many hackers and scripts.

Each web server should have its own web content directories. Each web application pool identity should have only the bare minimum access that it needs to each related content directory. Content directories should be structured to maximize security simplicity. Most administrators structure their Web site directories according to the Web sites' overall linking structure. For example:

     \Inetpub\wwwroot
     \Inetpub\wwwroot\Examplecom
     \Inetpub\wwwroot\Examplecom\Main
     \Inetpub\wwwroot\Examplecom\Company Structure
     \Inetpub\wwwroot\Examplecom\Mission
     \Inetpub\wwwroot\Examplecom\Recruiting

The administrators make subdirectory structures that mimic the linking structure and place all content into common parent directories that describe the Web site's logical structure. Most of the time, all the files in the same folder share the same permissions. This is completely wrong.

Instead, Web site folders should be structured along security lines, so that all content in the same directories truly describes common security permissions. The following code uses the preceding example but improves on it:

     \Temp\Web
     \Temp\Web\Examplecom
     \Temp\Web\Examplecom\HTML content
     \Temp\Web\Examplecom\HTML content\Main
     \Temp\Web\Examplecom\HTML content\Company Structure
     \Temp\Web\Examplecom\HTML content\Mission
     \Temp\Web\Examplecom\HTML content\Recruiting

     \Temp\Web\Examplecom\Scripts
     \Temp\Web\Examplecom\Scripts\Main
     \Temp\Web\Examplecom\Scripts\Company Structure
     \Temp\Web\Examplecom\Scripts\Mission
     \Temp\Web\Examplecom\Scripts\Recruiting

     \Temp\Web\Examplecom\Executables
     \Temp\Web\Examplecom\Executables\Main
     \Temp\Web\Examplecom\Executables\Company Structure
     \Temp\Web\Examplecom\Executables\Mission
     \Temp\Web\Examplecom\Executables\Recruiting

     \Temp\Web\Examplecom\Pictures
     \Temp\Web\Examplecom\Pictures\Main
     \Temp\Web\Examplecom\Pictures\Company Structure
     \Temp\Web\Examplecom\Pictures\Mission
     \Temp\Web\Examplecom\Pictures\Recruiting

Although this structure may look unnecessarily complicated at first, it's really simple. In the first example, the administrator would have to manually look at each file in each directory and determine what security it should have. In the latter example, the appropriate permissions can be set at the higher parent directories (such as HTML content, Scripts, Executables, Pictures) and all the related files automatically inherit the correct permissions. It may take a little bit longer to set up, but it saves in overall administration time and ensures greater security. The former model is bound to break down and cause a security issue. The latter structure ensures that good security occurs naturally.

Then using Windows Explorer (for NTFS permissions) and IIS Admin (for IIS permissions), set the bare minimum permissions needed for the Web site to function appropriately. Remember to tie NTFS permissions to the appropriate application pool identity and the appropriate impersonated user account.

Ensure that any IIS-related user accounts (such as IIS_IUSRS, web pool identity, and so on) do not have access to any files or folders that they should not have access to. There is no reason for IIS-related user accounts to have access to most high-risk files and folders. For example, unless there is a legitimate reason for the IIS_IUSRS group to have access to Cmd.exe, http://www.Command.com, or Debug.exe, give the IIS_IUSRS account Deny-Full Control permissions to those files. That way, if an IIS anonymous user account "breaks out" of IIS, the hacker won't be able to readily access the Windows command prompt, as they often attempt to do. This will defeat many hackers and hacking tools. Appropriately set permissions will help increase the security of any Web site.

Web Site IP Settings

Change the IP address of the Web site in the IIS Admin console to be a static private address instead of All Unassigned. This will prevent hackers from using unintended IP addresses to gain unauthorized access to the web server. Install the Web site to a non-default port (nearly anything but ports 80 and 443, as discussed earlier in the section "Configuring Network/Perimeter Security"), if possible. Moving web servers from ports 80 and 443 will do much to decrease the security risk of any affected Web site.

Application Pool Changes

As discussed previously, application pools and their identities should be locked down to just the files and folders they need to allow the Web site to function appropriately. Every Web site needing different security requirements should have its own application pool. Consider creating a custom identity service account, assigning it just the permissions it needs, and assigning it to the application pool.

After making the appropriate changes, stop and restart IIS to let new changes take effect. Then re-run MBSA to check for missing patches.

Cleaning and Testing

When setting up and patching any new computer, there are bound to be temporary files and folders left around. For example, you should delete the \wutemp folder left over by patching. Look for other temporary files and delete them, too. Then empty the Recycle Bin. Then reboot once more. Check error logs after bootup for any messages to investigate.

Installing and Securing Applications

Now for the even harder part: Securing an OS and IIS server is easy compared to installing a secure application. Many penetration experts swear they have never met a secure web application. Applications should be modeled and protected using the Security Development Lifecycle (http://www.msdn2.microsoft.com/en-us/library/ms995349.aspx). There are many books, articles, and classes on this subject. In a nutshell, SDL attempts to anticipate all the threats that are possible against a particular application, and builds in the security defenses as a part of the development lifecycle. SDL makes secure design a key part of the project and makes sure it is not "bolted on" at the end of the project. Every application undergoing SDL review at Microsoft has resulted in significantly fewer vulnerabilities, and the vulnerabilities that were found were less critical in nature.

Coders and the web server administrator should work together to ensure that a secure application gets installed on IIS, and that the bare minimum permissions have been defined and configured as discussed previously.

Conducting Penetration Tests

Open up the appropriate web server ports on the host-based firewall to allow for internal penetration testing. Penetration tests, regardless of whether they use their own wits or automated tools, should test the OS, IIS, and the application. Two good, free web server penetration testing tools are Nessus (http://www.nessus.org) and Nikto (http://www.cirt.net/code/nikto.shtml). Nessus comes in both Linux and Windows versions, and in both free and commercial forms. Nikto is an open source tool that requires Linux or Cygwin (http://www.cygwin.com/) to run in Windows environments. Nessus actually uses Nikto for its web penetration testing. Both products run hundreds of vulnerability tests on web servers. Any noted deficiencies should be corrected before go-live. Lessons learned should be incorporated into future roll outs.

Deploying to Production

Open the appropriate web server ports on the perimeter firewall and expose the Web site to the world. You've done your job well and there is little to worry about. Every Web site can be hacked, but yours should be one that is not easily cracked. You can also open the Web site to external penetration testing if another round of testing is required.

Monitoring Log Files

Last, monitor the firewall and log files located in the centralized log directory. Investigate critical or persistent threats.


Summary

Chapter 9 covers a number of recommended hardening procedures. Here's a recap:

  • Secure the physical and network perimeter.

  • Prevent booting from anything but the primary hard drive.

  • Password-protect BIOS from changes.

  • Install and correctly configure a perimeter firewall.

  • Patch hardware, BIOS, drivers, and so on before installing the OS or IIS.

  • Install the OS.

  • Don't install to a domain or Active Directory unless needed.

  • Configure secure remote administration.

  • Install RDP (if used) to a high, non-default port.

  • Install IIS in a minimal configuration and then run the patch update.

  • Harden the OS by removing unneeded software and services.

  • Require strong passwords.

  • Enable account lockouts.

  • Rename the Administrator and Guest accounts.

  • Remove the Everyone and Power Users groups from "Access this computer from the network" user right.

  • Remove the Backup Operators group from "Access this computer from the network" user right, unless remote backup is done.

  • Change the Unsigned Driver behavior from Warn to Don't Allow.

  • Enable Message Text for Interactive Logon (just to defeat any brute-force logon tools).

  • Disable Logon caching.

  • Enable the "Do not allow the anonymous access of SAM accounts and shares" option (although this may disable some remote management tools).

  • Enable the "Do not allow the storage of credentials or Passports for network authentication" option.

  • Enable the "Do not store Lan Man hash value on next password change" option.

  • Change LM Authentication Level to NTLMv2, and refuse LM and NTLM (unless you need down-level clients to authenticate using Integrated Windows authentication).

  • Enable the "Clear virtual memory page" file option (although this will cause long shutdown and bootup times, so measure use against availability concerns).

  • Remove Posix as an optional Windows subsystem.

  • Restrict CD-ROM and floppy drive use to local logged-on users only.

  • Deny the Log On Locally right to all members of the IIS_IUSRS group.

  • Enable the "Interactive Logon: Do not display user info" option.

  • Remove DFS$ and COMCFG from file shares that allow anonymous logon.

  • Disable File and Printer sharing.

  • Install additional IIS features and modules as needed.

  • Minimize Protocol Listeners, components, handlers, handler permissions, authentication methods, providers, scripts, ISAPI filters, applications, MIME types, and other unneeded IIS content.

  • Use Feature Delegation to restrict the number of admins and what each admin can do.

  • Strengthen NTFS permissions.

  • Design IIS directory structure to support strong security.

  • Configure URL Request Filtering.

  • Configure Web site(s) to use only the IP addresses they should be listening on.

  • Add additional application pools as necessary to segregate unrelated Web sites and content.

  • Create custom web pool identity and anonymous accounts as desired to further harden IIS.

  • Remove unnecessary files, including temp files, scripts, and so on.

  • Empty the Recycle Bin and reboot the server.

  • Install only security-reviewed applications.

  • Conduct vulnerability tests against the web server to test settings and configuration.


Chapter 10: Protecting E-mail

Malicious attack types come in cycles. Two decades ago it was boot viruses. In the mid 1990s, macro viruses reined. Malicious e-mails have been a huge problem since the Melissa virus in 1999 and the Iloveyou worm of 2000. These days, malicious e-mails account for the majority of the e-mail traffic headed across the Internet, albeit using bots, viruses, worms, spam, or phishing attacks.

Preventing malicious e-mail attacks is one of the strongest defenses any network administrator can implement. In this chapter, we discuss the various e-mail threats, introduce Windows Vista's new Windows Mail application, and discuss e-mail defenses that should be enacted to secure any environment.

E-mail Threats

E-mail threats come in the form of malicious file attachments, embedded content, embedded links, leaked passwords, and some other miscellaneous categories.

Malicious File Attachments

Malicious file attachments still account for a large majority of all e-mail threats, although the percentage is decreasing as attackers begin to rely on embedded content more and more. In most instances, a malicious file attachment must be manually opened or executed by the end user to launch the malicious program or instructions. There have been a few isolated cases and periods of time where file attachments have been able to automatically execute when the user retrieved the e-mail (for example, buffer overflows and MIME-type mismatches), but those types of flaws are usually patched quickly. In most cases the user is tricked into opening the file attachment, thereby firing off the exploit.

Note

As we go to print, Microsoft is releasing a new client e-mail application called Windows Live Mail. Although it is a separate download and will not be a mandatory install, Microsoft is strongly recommending that all Vista users that would otherwise use Windows Mail implement Windows Live Mail instead. We agree. Windows Live Mail includes all the security features of Windows Mail, plus additional features (e.g. authenticated POP, HTTP mail support, RSS feeds, etc.). Windows Live Mail will also be available as an optional update through the normal Windows Updates patch management channels. When Windows Live Mail is installed, it takes over all the e-mail entry and exit points from Windows Mail (although it does not do this by default if you have Microsoft Outlook installed). Windows Mail is deprecated, but will still be available for use, if needed. All future Windows e-mail clients will be innovated from Windows Live Mail. Although a few details may differ between the two versions, all of the e-mail recommendations made in this chapter apply equally to Windows Mail, Windows Live Mail, or any other e-mail client.

The e-mail often contains a forged sender e-mail address, an enticing message with various social engineering qualities, and an attached file. There are literally over 200 file types that have been used (or can be used) to launch malware. Table 10-1 lists file formats that have, or could be, used in malicious attacks. You'll also see that the table includes a malicious risk ranking for each file type. File types highlighted with bold type face are considered high risk for every organization. This means the file type is more likely to be used maliciously by unauthorized intruders or malware than legitimately by authorized users. Other file types, such as Microsoft Word or Microsoft Excel, are also high-risk, but they are still used legitimately the majority of the time. Administrators should always block the former high-risk file types from executing by default, and consider additional defense-in-depth techniques for minimizing attacks utilizing the latter file types.

Table 10-1: File Types That Have or Can Be Used Maliciously Open table as spreadsheet
FILE EXTENSION | MALICIOUS RISK | FILE TYPE | MALICIOUS USE DETAILS
.386 | Low | Windows virtual device driver (VxD) file | Essentially the same as an .exe file.
.acf | Medium | Microsoft Agent file | Microsoft Agent (http://www.microsoft.com/msagent/default.asp) file, which is used by the Microsoft Agent ActiveX control. Vulnerability patched in MS06-068.
.ade | Low | Microsoft Access Project file | Can contain auto-executing macros. Is not often used maliciously.
.adn | Low | Microsoft Access Project Template | Can contain auto-executing filemacros. Is not often used maliciously.
.adp | Low | Microsoft Access Project file | Can contain auto-executing macros. Is not often used maliciously.
.ani | Medium | Windows Animated Cursor | Two exploits were announced by Flashsky Fangxing (flashsky@xfocus.org) on December 23, 2004. First, a Windows Kernel DoS exploit-Windows XP SP2 not vulnerable, but most other Windows versions are (NT to 2003) are. Second, an Integer buffer overflow-most Windows versions are vulnerable (NT to 2003), caused by LoadImage API in USER32.Lib.
.arc | Low | PKArc file archive | Older, pre-Windows file archive file format. Still used occasionally by malware to bypass computer security defenses.
.arj | Medium | File Archive file | Can be used by malware to bypass computer security defenses. Arj files can be created and unarchived using many popular programs including Winzip. More detail on .arj program can be found at http://www.filext.com/detaillist.php?extdetail=ARJ.
.asf | Medium | Microsoft Advanced Streaming Format | Streaming audio or video files usually opened using Windows Media Player (WMP). ASF files can be exploited through buffer overflows, header malformation, or dangerous scriptable content. Can contain binary files, scripts, and HTML links, which can retrieve other content. ASF files can be renamed to other extensions (for example, MP3) and they will still be recognized as ASF files and opened in WMP. Great discussion on ASF and ASX files located at http://www.webreference.com/js/column51/asf.html.
.asx | Medium | Windows Media Player file | ASX files are Windows Media Player textual command files that manage streaming of ASF files. They are very small in size (about 1K) because they contain no data, just instructions. Can call and invoke many other types of active content. Involved in a reported DoS vulnerability reported to NTBugtrack on November 22, 2006. Great discussion on ASF and ASX files located at http://www.webreference.com/js/column51/asf.html.
.atf | Low | Symantec pcAnywhere autotransfer file | Can initiate a pcAnywhere file-transfer session.
.avi | Medium | Microsoft video file format | AVI stands for Audio Video Interleave. Has been used in some exploits, such as MS-05-050, which was caused by a DirectX graphics vulnerability. User could download file and be exploited, including allow remote file execution (but not privilege escalation).
.b64 | Medium | Base 64 MIME-encoded | Can be used to send MIME file attachments. Has been used to send malware.
.bas | Low | Visual Basic (VB) class module | Can contain malicious instructions. Association may not exist on newer PCs.
.bat | High | DOS batch file | Can contain malicious DOS command interpreter instructions.
.bhx | Medium | Winzip file archive | Has been used by a few worms to bypass antivirus scanners.
.bmp | Medium | Windows Bitmap graphics file | Integer buffer overflow, announced by flashsky fangxing (flashsky@xfocus.org) on December 23, 2004-most Windows versions are vulnerable (NT to 2003), caused by LoadImage API in USER32.Lib. Tough call, as this format is very popular for legitimate use.
.cab | Low | Microsoft cabinet archive file | Opens in Windows Explorer and IE, and can help install malicious files. Commonly used by Microsoft to install legitimate files, but could be used by malware to bypass computer security defenses. Unexpected CAB files arriving via e-mail or from untrusted Web sites should not be executed.
.cap | Low | Ethereal packet capture file | Contains network packets captured from a network protocol analyzer. Ethereal's dissectors (the filters that parse network packets into protocol disassemblies) are often subject to buffer overflows. But to date, no popular malware attack has used .cap files to exploit a computer.
.cbl | Medium | Microsoft Interactive Training file | User=field allows an exploitable buffer overflow (SEH pointer). Microsoft Interactive Training (Orun32.exe) must be present, although it is often present by default in OEM versions of Windows XP. First exploit of this file type announced on June 14, 2005 by iDEFENSE labs. Patched by MS05-31. HK_CR\MITrain.Document\shell\open\command is related to the Orun32.exe program.
.cbm | Medium | Microsoft Interactive Training file | User= field allows an exploitable buffer overflow (SEH pointer). Microsoft Interactive Training (Orun32.exe) must be present, although it is often present by default in OEM versions of Windows XP. First exploit of this file type announced on June 14, 2005 by iDEFENSE labs. Patched by MS05-31. HK_CR\MITrain.Document\shell\open\command is related to the Orun32.exe program.
.cbo | Medium | Microsoft Interactive Training file | User= field allows an exploitable buffer overflow (SEH pointer). Microsoft Interactive Training (Orun32.exe) must be present, although it is often present by default in OEM versions of Windows XP. First exploit of this file type announced on June 14, 2005 by iDEFENSE labs. Patched by MS05-31. HK_CR\MITrain.Document\shell\open\command is related to the Orun32.exe program.
.cer | Low | Digital certificate | Can be used to install a malicious certificate in IE to permit automatic downloading of malicious content
.ceo, ce0 | Low |  | Used by Winevar worm. NETCOM guidance 2004-11 recommends blocking this file extension.
.chm | High | Windows Compiled Help File | Windows Help Files (.hlp) can be compiled for better performance and feature sets. Malformed Compiled Help Files have been involved in many announced exploits over the years, including Microsoft Security Bulletin MS05-031 and exploits in 2006 (http://www.securityfocus.com/bid/17926/discuss). Can be opened in Internet Explorer automatically without user intervention using Ms-its moniker.
.cmd | High | Command file | Contains batch file-like DOS interpreter script commands. Can contain malicious instructions.
.cnt | Low | Microsoft Help Workshop Help Contents file | There is a stack-based memory corruption in Microsoft Help Workshop while processing .CNT Help Contents files. The tool is a standard component of Microsoft Visual Studio 6.0 and 2003 (.NET) for building and managing help projects and could be also downloaded alone from the Microsoft download center. Original announcement on January 18, 2007 (http://www.anspi.pl/~porkythepig/visualization/cnt-expl1.cpp).
.com | Medium | Program executable | Older, legacy DOS and 16-bit Windows executables. Still work under all Windows versions, except newer 64-bit Windows.
.cpl | High | Control Panelapplet | Executable program written to run in Control Panel context. Can be infected by viruses or used by malware programs to install themselves. Example includes a Win32.Beagle variant (http://www.securityresponse.symantec.com/avcenter/venc/data/w32.beagle@mm!cpl.html). Legitimate used all throughout Windows, but rarely needed to be accepted in e-mail, IM, and so on.
.crl | Low | Certificate Revocation List | CRL's list revoked digital certificates. Could be used in an attack to maliciously invalidate otherwise valid digital certificates in a denial of service attack.
.crt | Low | Digital Certificate | Can be used to install a malicious certificate in IE to permit automatic downloading of malicious content.
.cs | Medium | Windows scripting file | Scripting file that can be executed by Cscript.exe, can contain malicious commands.
.css | Medium | Cascading Style Sheet | Used by IE and other browsers. Used by web developers to easily deliver a consistent look-n-feel style to a Web site without having to recode the style each web page. Has been exploited maliciously many times. Should not be disabled in IE in most cases, but rarely needs to be sent in e-mail, IM, and so on.
.ctl | Low | Certificate Trust List | Could be used by remote attacker to trick victim into installing the attacker as a trusted publisher.
.cur | Medium | Windows cursor graphic file | Integer buffer overflow, announced by flashsky fangxing (flashsky@xfocus.org) on December 23, 2004, most Windows versions are vulnerable (NT to 2003); caused by LoadImage API in USER32.Lib.
.dbg | Low | Debug file | Can contain malicious machine language instructions that can be compiled by debug.exe into malware.
.desklink | Low | Desktop link to program | Could be used maliciously.
.der | Low | Digital Certificate | Can be used to install a malicious certificate in IE to permit automatic downloading of malicious content.
.dhtml | Low | Dynamic HTML file | Has been used in malicious attacks, but is not longer a popular attack vector.
.dif | Low | Data Interchange Format | Older common spreadsheet file format, commonly used in conversion. Has been used a few times in older malicious attacks.
.dll | High | Dynamic Linking Library | Most DLLs are legitimate program files containing pre-compiled library routines that other programs can call, or can contain complete programs. Have been involved in many viruses and worms. Because of Windows File Protection, most Windows system dlls cannot be overwritten or modified by malware, but rogue dlls can be installed.
.doc | High | Microsoft Office Word document | Can contain malicious macros, scripts, objects, links, and executables. Very difficult to block because legitimate use is very common. By default, many malicious objects are blocked by default Microsoft Office security settings. Note that recently many Office document formats have been targeted for zero-day attacks.
.dochtml | Low | Microsoft Office Word document in HTML format | Can contain malicious macros, scripts, objects, links, and executables. Very difficult to block because legitimate use is very common. By default, many malicious objects are blocked by default Microsoft Office security settings.
.docmhtml | Low | Microsoft Office Word document in MIME encapsulated format | Can contain malicious macros, scripts, objects, links, and executables. Not commonly used. By default, many malicious objects are blocked by default Microsoft Office security settings.
.docxml | Low | Microsoft Office Word Document | Can contain malicious macros, scripts, objects, links, and executables. By default, many malicious objects are blocked by default Microsoft Office security settings.
.dot | Medium | Microsoft Office Document Template | Can be manipulated by malware to contain malicious objects that are then added to every new document that relies on the related template file. Very commonly manipulated by early Microsoft Office macro files, but not as commonly modified by malware today.
.dothtml | Low | Microsoft Office Document Template in HTML format | Can be manipulated by malware to contain malicious objects that are then added to every new document that relies on the related template file.
.dsm | Medium | Nullsoft WinAmp media file | Has been involved in malicious exploits.
.dun | Low | DUN export file | Can contain malicious dial-up connection information that initiates outward calls.
.edt | Low | Adobe Reader PDF ebook file | Involved in at least one announced exploit (http://www.idefense.com/application/poi/display?id=163) in 2004. If ebook functionality is not needed, it can be blocked without affecting overall Adobe Reader functionality.
.email | Medium | Outlook Express e-mail message | Used by Nimda and many other worms.
.emf | Medium | Enhanced Metafile file | Windows graphics file format buffer overflow, MS05-053. High criticality if not patched. In January 2007, also found to be vulnerable in OpenOffice versions prior to 2.1.0 and Star Office versions prior to 8.
.eml | Medium | Outlook Express e-mail message | Used by Nimda and many other worms.
.eot | Low | Embedded Open Type font | Malicious font file could be used to take complete control of an unpatched Windows computer. Patch is MS06-002. Font extension is normally .eot, but could be anything.
.exe | High | Application file | Can be used to launch malicious executables. Cannot block on a Windows system, but should be blocked in e-mail, IM, and so on.
.far | Medium | Nullsoft WinAmp media file | Has been involved in malicious exploits.
.fav | Low | IE Favorites list | Can be used to list malicious Web sites. Don't block on Windows, but block coming through e-mail, IM, and so on.
.gadget | Medium | Vista Sidebar Gadget | Sidebar gadgets can contain nearly any type of Active content and scripting. They can be sent in e-mail and downloaded from the Internet. There is a good chance that malware writers will try to take advantage of Vista's new Sidebar gadgets feature.
.gif | Low | Graphic file format | GIF stands for Graphics Interchange Format. Although normally just a picture or image data file. It has been malformed to cause improper application handling and buffer overflows in many applications, including IE, Windows Messenger (see Microsoft Security Bulletin MS05-022), and Sun's Java (http://www.frsirt.com/english/advisories/2007/0211). Sun Java exploit announcement.
.gzip | Low | Gzip file format | Can be used by malware to bypass computer security defenses. Very common on Unix/Linux platforms, but can also be used in Windows. See .tar also.
.hhp | Medium | Microsoft HTML Help Workshop file | Used in buffer overflow exploit announced February 2006 (http://www.frsirt.com/english/advisories/2006/044).
.hlp | Medium | Microsoft Help File | Used legitimately throughout Windows, but has been used in multiple exploits. Block in e-mail, IM, and so on.
.hpj | Low | Microsoft Workshop Help File | Microsoft Help Workshop 4.03 .0002 is a standard component of Microsoft Visual Studio 6/2003 (.NET). It can also be downloaded alone from the Microsoft download center. January 22, 2007 exploit located at http://www.anspi.pl/~porkythepig/visualization/hpj-x01.cpp.
.hqx | Low | Macintosh BinHex 4 Compressed Archive | Has been used to spread malware.
.ht | Low | Hyperterminal file | Can initiate dial-up connections to untrusted hosts.
.hta | High | HTML application | Frequently used by worms and Trojans.
.htm | High | HTML file | Can initiate an Internet browser session and can be used to automatically download and execute rogue files.
.html | High | HTML file | Can initiate an Internet browser session and can be used to automatically download and execute rogue files.
.htt | Low | Internet Explorer stylesheet | Can be used/manipulated by adware/malware to display unwanted browser Windows and popups.
.ico | Medium | Windows Icon graphic file | Was involved in an integer buffer overflow, announced by flashsky fangxing (flashsky@xfocus.org) on December 23, 2004; most Windows versions were vulnerable (NT to 2003) before the patch was released. The vulnerability was caused by LoadImage API in USER32.Lib.
.idc | Medium | Interactive Disassembler application file | Normally only used by IDA Pro Disassembler (http://www.datarescue.com/idabase). Can be used by viruses. Proof of Concept virus was released (http://www.sarc.com/avcenter/venc/data/w32.gatt.html).
.inf | Low | Install configuration file/security | As a Setup Information installer template configuration file, it can be used to maliciously manipulate existing programs or to install new malicious programs. As a security template, it can be used to downgrade existing security permissions.
.ini | Low | Application configuration settings file | Can be used to maliciously change a program's default settings. Also, Desktop.ini can be used to auto-launch malicious programs.
.ins | Low | Internet communication settings | Can be used to initiate Internet connections to untrusted sources.
.iso | Low | Image file for disks, CD-ROMs, DVDs, etc. | There is worm that can arrive and spread using iso images. Very low risk. See http://www.trendmicro.com/vinfo/images/WORM_BAHISHO_A2.gif for more details.
.isp | Low | Internet communication settings | Can be used to initiate Internet connections to untrusted sources.
.it | Medium | Nullsoft WinAmp media file | Has been involved in malicious exploits.
.its | High | Microsoft Infotech Storage Library | Has been used in buffer overflows. Not installed by Microsoft by default, can be installed by many legitimate "teaching" programs. Related to compiled help file exploit (http://www.securityfocus.com/bid/17926/discuss).
.jar | Low | Java archive file | Can launch Java attacks.
.jav | Low | Java applet | Can launch Java attacks.
.java | Low | Java applet | Can launch Java attacks.
.jfif | Low | JPEG File Interchange File Format | The JPEG graphics file format has been involved in a few buffer overflows, including Microsoft MS04-028.
.jpe | Low | JPEG graphics files | The JPEG graphics file format has been involved in a few buffer overflows, including Microsoft MS04-028.
.jpeg | Low | JPEG graphics files | The JPEG graphics file format has been involved in a few buffer overflows, including Microsoft MS04-028.
.jpg | Low | JPEG graphics file | The JPEG graphics file format has been involved in a few buffer overflows, including Microsoft MS04-028.
.js | High | JavaScript file | Can contain malicious code that can easily be decoded and read by Windows and IE. These files are executed by Wscript.exe, Cscript.exe, or JScript.dll.
.jse | Medium | Encoded JavaScript file | Can contain malicious code. JSE files are encoded JavaScript files that can easily be decoded and read by Windows and IE. These files are executed by Wscript.exe, Cscript.exe, or JScript.dll. JSE files are as easy to create as JavaScript files, but haven't been popularly used so far.
.key | Low | Windows Registry modification file | Could contain malicious Registry keys and values.
.lnk | Low | Shortcut link | Can be used to automate malicious actions.
.lsf | Low | Streaming audio or video file | Can be exploited through buffer overflows, head malformation, or dangerous scriptable content.
.lsx | Low | Streaming audio or video file | Can be exploited through buffer overflows, head malformation, or dangerous scriptable content.
.lzh | Medium | Archive file format | Can be used by malware to bypass computer security defenses. Is used on Windows platforms, especially by game developers or Japanese programmers, but is not common.
.m3u | Low | XMPPlay audio file | XMPlay is an audio player, supporting different audio formats and playlists. XMPlay was shown to be buffer overflow-exploitable on November 20, 2006, http://www.milw0rm.com/exploits/2815. XMPlay can also be buffer overflowed by ASX files (http://www.milw0rm.com/exploits/2824).
.mad | Low | Microsoft Access module shortcut | Can carry out macro manipulation that isn't controlled by Office security settings.
.maf | Low | Microsoft Access module form | Can contain malicious behavior.
.mag | Low | Microsoft Access module diagram | Can contain malicious behavior.
.mam | Low | Microsoft Access module macro | Can contain malicious behavior.
.maq | Low | Microsoft Access module query | Can contain malicious behavior.
.mar | Low | Microsoft Access module report | Can contain malicious behavior.
.mas | Low | Microsoft Access module stored procedure | Can contain malicious macros and procedures.
.mat | Low | Microsoft Access module table | Can contain malicious behavior.
.mav | Low | Microsoft Access module view | Can contain malicious behavior.
.maw | Low | Microsoft Access module shortcut | Can contain malicious behavior.
.mda | Low | Microsoft Access extension | Can contain malicious behavior.
.mdb | Low | Microsoft Access application or database | Can contain malicious behavior.
.mdbhtml | Low | Access application or database in HTML format | Can contain malicious macros.
.mde | Low | Microsoft Access database with all modules compiled and source code removed | Can contain malicious macros.
.mdn | Low | Microsoft Access database template | Can contain malicious behavior.
.mdt | Low | Microsoft Access database wizard file | Can contain malicious behavior.
.mdz | Low | Microsoft Access database wizard template file | Can contain malicious behavior.
.mht | Medium | MIME HTML document | Can contain malicious content.
.mhtml | Medium | MIME HTML document | Can contain harmful commands.
.mid | Medium |  | Malformed header has been used to buffer overflow Windows Media Player (http://www.frsirt.com/english/advisories/2006/5039).
.midi | Medium |  | Malformed header has been used to buffer overflow Windows Media Player (http://www.frsirt.com/english/advisories/2006/5039).
.mim | Medium | MIME-encoded file or archive file | Is a MIME (Multipurpose Internet Mail Extensions) file. Many e-mail clients, including sometimes Outlook and OE, create a .MIM file when forwarding an e-mail with an attachment. Attachment could be anything. In malicious e-mails, the .MIM attachments are often zip or executable files. See http://www.securityresponse.symantec.com/avcenter/venc/data/w32.blackmal.e@mm.html.
.mmf | Low | Microsoft Mail or Outlook item file | Can carry malware.
.mov | High | Quicktime movie files | Involved in multiple vulnerabilities over the years, including buffer overflows announced on 11/10/05 and 12/20/05 (http://www.frsirt.com/english/advisories/2005/3012).
.msg | Low | Microsoft Mail or Outlook Express item | Can carry malware.
.msh | Low | Microsoft Shell Command file | New file format in Windows Vista, used to replace previous shell language files (.bat, .cmd, and so on). Demonstration viruses have already been developed exploiting this file format (http://www.f-secure.com/v-descs/danom.shtml).
.msi | Medium | Microsoft Installer package | Can be used to install or modify software.
.msp | Low | Microsoft Installer package | Can be used to install malware.
.mst | Low | Visual Basic test source file | Can be used maliciously.
.nch | Low | Outlook Express folder | I could not find how this was used to spread malware. Many malware programs look inside legitimate NCH files to find more e-mail addresses to spread to. However, NETCOM guidance 2004-11 recommends this file extension be blocked, so I mention it here just in case.
.nrg | Low | Nero cd-rom or dvd image file | There is a very low-risk worm that can spread using Nero image files. See http://www.trendmicro.com/vinfo/images/WORM_BAHISHO_A2.gif for more details.
.nws | Low | Outlook Express news message | Network newsgroup protocol. Can carry viruses, worms, and other malware.
.ocx | High | ActiveX control | Can be used to install malicious ActiveX programs.
.oft | Low | Outlook Template file | Outlook Template file can contain malicious scripting or objects. Not commonly used by malware. e-mail worms and viruses can sometimes harvest legitimate e-mail addresses from OFT files.
.oss | Low | Microsoft Office Saved Searches file | Can be used to exploit unpatched versions of Microsoft Windows/Outlook/Office. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0034
.ovl | Low | Program overlay file | Commonly used by legitimate programs. Can be used to install malware or legitimate ones can be infected by viruses.
.pcap | Low | Ethereal packet file | Can be used to buffer overflow capture Ethereal, not popularly used to exploit.
.pct | Low | Apple PICT graphics file | Used in QuickDraw and QuickTime applications, among other applications. Buffer overflow announced in both Windows and Unix on November 11, 2005.
.pdc | Low | Microsoft compiled script | Can contain dangerous code.
.pdf | Medium | Adobe Reader Portable Document Format | Involved in several exploits over the years. Difficult to block because of widespread legitimate use.
.pi | Medium |  | On some systems, PIF files come across as .pi, or so I've been told. NETCOM 2004-11 recommends that it be blocked.
.pic | Low | Apple PICT graphics file | Used in QuickDraw and QuickTime applications, among other applications. Buffer overflow announced in both Windows and Unix on November 11, 2005.
.pict | Low | Apple PICT graphics file | Used in QuickDraw and QuickTime applications, among other applications. Buffer overflow announced in both Windows and Unix on November 11, 2005.
.pif | High | Program information file | Can run malicious programs.
.pl | Medium | Perl script file | Can contain rogue code.
.pls | Medium | Winamp Playlist | Malformed playlist file (containing overly large filenames) can cause a buffer overflow in Winamp (http://www.frsirt.com/english/advisories/2006/0361).
.png | Medium | Portable Network Graphics file | PNG is an open source graphics format with lossy compression (http://www.libpng.org/pub/png). Has been involved in several exploits, including multi-browser buffer overflows. Last PNG IE buffer overflow resolved by MS05-025.
.pol | Low | Windows Policy File | Can be used to lower security settings on Windows 9x and above machines.
.pot | Low | Microsoft PowerPoint template file | Can contain scripted exploits.
.pothtml | Low | Microsoft PowerPoint template file in HTML format | Can contain malicious content.
.ppa | Low | Microsoft PowerPoint add-in | Can contain malicious content.
.ppt | Low | Microsoft PowerPoint presentation | Can contain malicious content.
.ppthtml | Low | Microsoft PowerPoint presentation in HTML format | Can contain malicious content.
.pptmhtml | Low | Microsoft PowerPoint presentation in MIME-encoded HTML format | Can contain malicious content.
.prf | Low | Outlook profile settings | Can override default or trusted settings.
.pst | Low | Outlook or Exchange personal store file | Can contain malicious attachments and be imported into Outlook or Outlook Express.
.pwl | Low | Windows 9x password file | Could be used to overwrite legitimate passwords in Windows 9x.
.py | Low | Python script file | Can contain rogue code.
.qtl | Medium | Quicktime Media Link | QTL files allow flexibility in the way that Quicktime files are accessed. QTL files can hold Javascript coding. QTL files can end in any extension (For example, MP3, MOV, QT). Has been used in at least one widespread XSS attack (http://www.gnucitizen.org/blog/myspace-quicktime-worm-follow-up).
.qtif | Medium | Quicktime file | Can be used to accomplish a buffer overflow in vulnerable versions of QuickTime (http://www.frsirt.com/english/advisories/2006/0128).
.rar | Medium | WinRAR archived files | Being used by malware to bypass detectors that normally open zip files, but don't open RAR files. Used by Bagle worm among others. http://www.geocities.com/marcoschmidt.geo/rar-archive-file-format.html
.rat | Low | Internet Explorer content ratings file | Part of Internet Explorer's content advisor rating feature. Can be installed to allow malicious Web sites to be approved as secure. Also can be used on IIS Web sites to pre-rate content to be delivered to visitors. If installed on IIS, could be used to execute malicious program instructions. Has been involved in a malicious buffer overflow announcement in the past.
.rc | Low | Microsoft Visual Studio file | http://www.secunia.com/advisories/23856. Affected products: Microsoft Visual Studio 6 SP6 and prior.
.rdp | Low | Remote Desktop Top connection shortcut | If an end user can be tricked into running a malicious RDP file, it could execute local commands, or map a drive (should provide warning in XP Pro and above) to remote malicious machine and give attacker access to local files. Currently not popularly exploited.
.reg | Low | Registry entry file | Can create malicious registry keys or values.
.rjs | Medium | RealPlayer skin file | Can be downloaded and applied automatically through a web browser without the user's permission. A skin file is a bundle of graphics and an .ini file, stored together in ZIP format. Fixed in RealPlayer versions above 10.5.
.rm | Medium | RealPlayer media file | Involved in multiple vulnerabilities over the year. The latest buffer overflow was announced on November 10, 2005.
.rpt | Low | Crystal Reports report file | RPT file has been used in multiple buffer overflow exploits. First reported in November 2006 (http://www.frsirt.com/english/advisories/2006/4691), and again in January 2007 (http://www.lssec.com/advisories/LS-20061102.pdf). RPT file extension represents many other types of "report files" and isn't used exclusively in Crystal Reports. Other .rpt file formats have not been reported as vulnerable.
.rtf | Medium | Rich Text Format file | Can script other attacks and contain embedded malicious links.
.scf | Medium | Windows Explorer command | Could be used maliciously in future attacks.
.scp | Low | DUN script | Can initiate rogue outbound connections.
.scr | High | Windows screen saver file | Usually legitimate, but can contain worms or Trojans, and has been used in many popular worm attacks in the past. Essentially, an SCR file is the same as an any other EXE file, and can do anything to a system.
.sct | Medium | Windows scriptlet file | Can contain malicious commands.
.shb | High | Shell scrap object | Can mask rogue programs by containing links to other programs. Shell scrap file objects can have hidden extensions even when Windows is told to display hidden file extensions.
.shs | High | Shell scrap object | Can mask rogue programs by containing links to other programs. Shell scrap file objects can have hidden extensions even when Windows is told to display hidden file extensions.
.shtml | Low | HTML file with server-side include directives | Could contain malicious content, but not popularly used.
.sit | Low | Mac Stuff-it compression archive file | Could be used to sneak malware past antivirus scanners.
.slk | Low | Excel SLK data-import file | Can contain hidden malicious macros.
.smi | Medium | RealPlayer file | Real Networks RealPlayer Synchronized Multimedia Integration Language (SMIL) file parser in RealPlayer was found to have a buffer overflow in March 2005 by eEye.
.smil | Medium | RealPlayer file | Real Networks RealPlayer Synchronized Multimedia Integration Language (SMIL) file parser in RealPlayer was found to have a buffer overflow in March 2005 by eEye.
.spl | High | Shockwave Flash object | Flash files have been involved in multiple exploits.
.stl | Low | Certificate Trust List (CTL) | Can induce user to trust a rogue certificate.
.stm | Medium | Nullsoft WinAmp media file | Has been involved in malicious exploits.
.swf | High | Shockwave Flash object | Flash files have been involved in multiple exploits, including MS06-020 released in May 2006.
.sys | Medium | Driver or configuration file | Used by many autorun files, including config.sys. Can be used to install malicious programs. Legitimate .sys files can be infected by viruses.
.tar | Medium | Unix archive file format | TAR stands for Tape Archive file format. Common Linux/Unix archive file format, but is used in Windows. Can be used by malware to bypass computer security defenses.
.TAZ | Medium | Unix archive file format | Can be used my malware to bypass computer security defenses.
.tga | Medium | Quicktime file | Can be used to accomplish a buffer overflow in vulnerable versions of Quicktime (http://www.frsirt.com/english/advisories/2006/0128).
.tgz | Medium | Unix archive file format | Can be used by malware to bypass computer security defenses.
.tif | Low | Common graphics file format | Has been involved in exploits before.
.tiff | Low | Common graphics file format | Has been involved in exploits before.
.tz | Medium | Unix archive file format | Can be used to accomplish a buffer overflow in vulnerable versions of Quicktime (http://www.frsirt.com/english/advisories/2006/0128).
.ult | Medium | Nullsoft WinAmp media file | Has been involved in malicious exploits.
.url | High | Internet shortcut | Can connect user to malicious Web site or launch a malicious action.
.uu | Low | Older (UUENCODE) archive file format | UUecode file format used to send program files and other objects through plain-text e-mail. Used to be common across most PC platforms, but is not super common today. Can be used by malware to bypass computer security defenses.
.uue | Low | Older (UUENCODE) archive file format | UUecode file format used to send program files and other objects through plain-text e-mail. Used to be common across most PC platforms, but is not super common today. Can be used by malware to bypass computer security defenses.
.xxe | Low | XX-encoded file | See http://www.membrane.com/synapse/library/uuenc.html for more information on xx-encoding. Recommended to be blocked by NETCOM 2004-11 guidance document.
.vb | Medium | VBScript file | Can contain malicious code that will be launched in Windows and IE and executed by Wscript.exe, Cscript.exe, or VBScript.dll.
.vbs | High | VBScript file | Can contain malicious code that will be launched in Windows and IE and executed by Wscript.exe, Cscript.exe, or VBScript.dll.
.vbe | Medium | Encoded VBScript file | Can contain malicious code. VBE files are encoded VBScript files that can easily be decoded and read by Windows and IE. These files are executed by Wscript.exe.
.vcf | Medium | vCard file format | Used in many e-mail clients, including Outlook and Outlook Express to communicate recipient addressing details. Has been involved in a few exploits.
.vxd | High | Virtual device driver | Can be used to execute malicious code.
.wab | Medium | Outlook Express Address book | Has been used in remote buffer overflow. See http://www.microsoft.com/technet/security/Bulletin/MS06-016.mspx and MS06-076.
.wbk | Low | Microsoft Word backup document | Can contain malicious content.
.wiz | Low | Microsoft Word Wizard file | Used by Microsoft to launch enduser-friendly "wizards" that walk new users through common tasks. Could be used to automate future social engineering attack, but is not a common malware vector.
.wma | Medium | Nullsoft WinAmp media file | Has been involved in malicious exploits.
.wmf | Medium | Windows metafile | Has been involved in multiple buffer overflow exploits, including MS05-053 and another exploit discovered on December. 27, 2005. Bug is Microsoft's Graphics Rendering Engine. WMF files can be named to other extensions that will still execute as if they are WMF files. In January 2007, it was also found to be vulnerable in OpenOffice versions prior to 2.1.0 and Star Office versions prior to 8.
.ws | High | WSH script file | Windows script file, executed by Wscript.exe, can execute malicious code.
.wsc | High | Windows scriptlet file | Windows script file, executed by Wscript.exe, can execute malicious code.
.wsf | High | WSH script file | Windows script file, executed by Wscript.exe, can execute malicious code.
.xla | Low | Microsoft Excel add-in program | Add-ins can contain dangerous macros and code.
.xlb | Low | Microsoft Excel file | Can contain harmful content.
.xlc | Low | Microsoft Excel Chart | Can contain harmful content.
.xld | Low | Microsoft Excel dialog box file | Can contain malicious content.
.xlk | Low | Microsoft Excel Backup file | Can contain malicious content.
.xll | Low | Microsoft Excel file | Can contain malicious content.
.xlm | Low | Microsoft Excel macro file | Can contain malicious content.
.xls | High | Microsoft Excel spreadsheet | Can contain dangerous macros and code.
.xlshtml | Low | Microsoft Excel spreadsheet in HTML format | Although not popularly used, can contain malicious content.
.xlsmhtml | Low | Microsoft Excel spreadsheet in MIME-encoded HTML format | Although not popularly used, can contain malicious content.
.xlt | Low | Microsoft Excel spreadsheet template file | Could contain malicious content.
.xlthtml | Low | Microsoft Excel spreadsheet template in HTML format | Could contain malicious content.
.xlv | Low | Microsoft Excel Visual Basic module | Can contain malicious content or commands.
.xml | Low | XML file | Likely to be the next language of choice for malicious coders.
.xsl | Low | XML conversion/translation file | Likely to be the next language of choice for malicious coders.
.z | Low | Gzip file format | Can be used by malware to bypass computer security defenses. Very common on Unix/Linux platforms, but can also be used in Windows.
.zip | High | Pkzip or Winzip archive file | Can be used maliciously several ways, including: 1) To allow malware to bypass file integrity checkers and antivirus software that does not unzip zip files. 2) Can contain a zip file within a zip file (several levels of nesting possible) to bypass security programs that do not do recursive scanning. 3) Can be used to auto-launch programs when file is unzipped. 4) Can be used to overwrite other legitimate files. 5) Can be used to create an overwhelming number of directories and subdirectories causing quota problems, low disk space, and other operating system abnormalities. Latter problem has also been used to bypass security programs that do not handle long and "deep" directory names well.

Table 10-1 is quite a lengthy list. Essentially, it is good evidence that nearly any file type can be maliciously manipulated to take advantage of an application's vulnerability. In addition, depending on how the file is launched, the operating system may consider a file as executable regardless of the extension. For instance, open a command prompt and run the following commands:

C:\Users\Jesper\Downloads>copy %systemroot%\notepad.exe dummy.duh
        1 file(s) copied.

C:\Users\Jesper\Downloads>dummy.duh

When you execute dummy.duh, Notepad launches. The command shell "peeks" into the file header and executes anything that looks like an executable even if the extension is something else altogether. If you double-click dummy.duh in Windows Explorer, you get an "unknown file extension" dialog box because Windows Explorer does not do the same thing. In other words, extensions are a poor way to judge whether something is executable or not. For reference, Internet Explorer also peeks into files to determine what they really are to decide how to handle them.

Security engineers should realize that every file type should be considered as a potentially malicious avenue until proven otherwise and plan their computer defense accordingly. Figure 10-1 shows a malicious screensaver executable (.scr) sent via e-mail.

Image from book
Figure 10-1: Screensavers are basically executables.
Note

I had to use an old pre-Windows Mail example for Figure 10-1, as Windows Mail will not display many potentially malicious file types and cannot be used to demonstrate the vulnerability. This is discussed in more detail in the material that follows.

File Extension Tricks

Many users don't understand the malicious risk posed by file attachments, and will gladly launch any file attachment, regardless of the file type. But the years of the ongoing onslaught of spam and phishing attacks have made many users more savvy. They will avoid executing untrusted executables (.EXE, .BAT, and so on), but open picture files, data file formats, videos, and other "safe" file types. As Table 10-1 shows, data and multimedia formats are often used to spread malware. In the last 18 months, application document formats, such as Office files, have been increasingly used to spread targeted zero-day attacks. This means that many file types that were previously thought to be "safe" are no longer very safe.

Other times, malware creators attempt to masquerade their "more malicious" file type as a "safe" file type. For instance, because Windows (by default) will hide registered file extensions, executable malware named Readme.txt.exe can sometimes appear as Readme.txt when presented as a file attachment. Figure 10-1 shows another trick, where the real file extension is placed to the far right of the fake file extension in an attempt to fool the user. What might look like Message.doc is really Message.doc <lots of spaces>.exe. The e-mail creator even placed a fake antivirus message in the text of the e-mail body in order to further fool an unsuspecting reader.

Note

I had to use an old pre-Windows Mail example for Figure 10-2, as Windows Mail is not subject to the multiple file extension trick and cannot be used to demonstrate the vulnerability.

Image from book
Figure 10-2: Moving the extension away from the file is often used to fool users.

Or another example: a file named Readme.1st could really be an MS Word document utilizing an unpatched vulnerability. As shown in Figure 10-3, Microsoft Office documents can be named with any file extension not already registered in Windows, and still open automatically in the referenced Microsoft Office application because Windows peeks into the file format, as described earlier.

Image from book
Figure 10-3: File extensions are not a good way to make security decisions.

Embedded Content

Most e-mail clients allow sending and receiving of web-based HTML content inside of an e-mail. Malicious attackers will often craft web-based attacks and send them as an e-mail. The unsuspecting user opens the e-mail, and the e-mail client renders the embedded HTML content. Several years ago mail clients ignored basic security recommendation and automatically displayed executable HTML content when the e-mail was opened or viewed. Any executable content would automatically display and any malicious code would automatically launch. Unless the very newest mail clients, such as Outlook 2007 or 2003, are universally used, allowing incoming e-mail to contain non-text content is among the riskiest computing behaviors around.

Embedded Links

Malicious e-mails often contain embedded URL links that, when clicked, take users to malicious Web sites, execute rogue code, or launch dangerous scripts. Figure 10-4 shows a link pointing to a malicious executable.

Image from book
Figure 10-4: By hovering over a link in an e-mail, you can see where the link actually goes.

This technique is almost universally used for phishing attacks, where users are lured to submit personal information to a rogue Web site. Hovering over the link will display the link, but that in and of itself is often very difficult to parse and often the link goes somewhere illegitimate. For instance, all the popular search engines allow redirection from the search engine to other sites. A link that seems to go to http://www.google.com/ <some strange stuff here> may actually land you on a rogue Web site somewhere.

Leaked Passwords

Last, many e-mail protocols are well known for passing e-mail server logon credentials in clear text between the client and server. Malicious intruders can sniff network traffic and find the user's logon name and password, which can then be used outside of e-mail. Figure 10-5 shows a sniffed POP3 network connection revealing the user's logon name and password.

Image from book
Figure 10-5: Many e-mail protocols are clear-text.

Corporate e-mail protocols are typically not clear-text protocols. For instance, an organization that uses Exchange Server typically uses native Windows authentication, which is far more secure. However, IMAPv4 and POP3, two very common protocols in academia and with Internet service providers (ISP), are both clear-text.

Other Miscellaneous E-mail Threats

Malware writers can use e-mails in many other malicious ways. Phishing attacks can induce the reader into revealing their logon name, passwords, and other financial identity information to criminals. "Nigerian" scams (http://www.en.wikipedia.org/wiki/Advance_fee_fraud) have led to innocent people losing tens of millions of dollars and even being murdered. Lest you think only idiots fall for these types of scams, Nobel prize-winners in physics and many millionaires have been taken in by e-mail scams. Being smart doesn't always override the alluring promise of get-rich-quick schemes.

E-mails have also been used to execute buffer overflows on e-mail servers and clients. During the last few years, several antivirus software programs that are supposed to protect e-mail users have been susceptible to buffer overflows from specially crafted e-mails. When the antivirus program inspected incoming e-mail attachments, a buffer overflow was used to take over the server or exploit the client. Security vulnerabilities in security software are not uncommon and reveal one of the risks when utilizing third party defensive software.

Business users often access personal e-mail accounts using computers owned by their organizations while on the organizational network. Whether using an Internet browser or using a normal e-mail client, personal e-mail accounts present a risk to the organizational computing environment by bypassing the corporate e-mail protection mechanisms. Particularly, web-based mail access presents a very high risk. While Outlook or Windows Mail may block high-risk file attachments, a web-based e-mail account may still allow malicious file attachments or embedded content to be transferred and executed. Whether this risk is acceptable needs to be addressed in the organizational security policy. It needs to be considered in light of the hardship posed by not permitting people to access their personal e-mail at work. Blocking personal e-mail access will almost certainly result in a significant increase of organizational e-mail volume as people shift to using their work-based e-mail system for personal use.


Introducing Windows Mail

The popularity of e-mail attacks led Microsoft to completely re-write the Windows e-mail client. The new version was renamed Windows Mail to differentiate from prior versions of Outlook Express and Outlook. While substantial changes have been made to Windows Mail, this section will focus on the security improvements. New security features include:

  • Phishing detection

  • Improved junk mail detection

  • Sender white lists and black lists

  • Top-level domain blocking

  • Character set blocking

  • Simplified e-mail storage

Note

Several popular, but risky, Outlook Express features have been removed in Windows Mail, including the ability to have multiple e-mail identities and HTML e-mail account support (HTML support is available in Windows Live Mail). Keep in mind, however, that Windows Mail is exclusively considered a personal e-mail client. It is not intended to access organizational mail servers, such as Microsoft Exchange Server. For readers who are solely interested in organizational e-mail protection, this section may prove of interest only insofar as it highlights security steps that should be taken in the mail clients they use. Microsoft Outlook 2007 contains many of the same improvements seen in Windows Mail.

Phishing Detection

Phishing e-mails continue to be a huge problem, and are predicted to remain at a high percentage of overall makeup rate or grow over the next few years. Windows Mail contains built-in phish detection that is separate from Internet Explorer 7's new anti-phishing mechanisms. All incoming e-mail is inspected for characteristics and content associated with phishing messages.

As Figure 10-6 shows, Windows Mail isn't shy about pointing out suspected phishing messages. It highlights the e-mail summary in red and gives the user the ability to unblock or to delete the message.

Image from book
Figure 10-6: Windows Mail is very conspicuous about suspected phishing messages.

The anti-phishing feature can be disabled or modified as shown in Figure 10-7.

Image from book
Figure 10-7: The anti-phishing features can be disabled or modified.
Note

Windows Live Mail's ability to move phish e-mail to the Junk Mail folder only applies to e-mail arriving POP and IMAP (and not HTTP).
Note

Look for many of the e-mail security settings discussed in this chapter under E-mail safety options under the Tools menu bar option in Windows Live Mail.

Improved Junk Mail Detection

Client-side junk mail detection has been added to Windows Mail. Several detection levels (as shown in Figure 10-8) are available, along with a built-in Junk e-mail folder.

Image from book
Figure 10-8: Windows Mail contains client-side junk-mail protection.
Note

Windows Live Mail has the additional ability to report e-mail marked as Junk Mail to Microsoft and its partners in order to increase overall junk e-mail detection accuracy through end-user community involvement.

Sender White Lists and Black Lists

By default, all e-mail recipients are added to Windows Mail's Safe Sender white list (see Figure 10-9), although additional e-mail addresses can be added as well.

Image from book
Figure 10-9: Windows Mail contains a "Safe sender" list feature.

Messages from people on the Safe Sender list are never blocked as junk mail. Windows Mail also comes with an e-mail black list under Blocked Senders (see Figure 10-10), although e-mail address-level black lists are of limited value in most environments. Phishers and spammers rarely re-use an e-mail address after its use in a malicious campaign.

Image from book
Figure 10-10: The "blocked senders" list may primarily be useful to block messages from people you do not want to talk to.

Top-Level Domain Blocking

Many foreign countries are doing a poor job at blocking malicious e-mail senders. Some countries appear to actually encourage it and offer safe havens to spammers and phishers. Windows Mail allows a user to block all e-mails from a top-level domain (TLD) (for example, an entire country). As Figure 10-11 shows, Windows Mail offers various country top-level domains to choose from. While not overly accurate, Windows Vista allows the user to set country-specific blocks.

Image from book
Figure 10-11: You may block messages from a particular TLD.
Note

Windows Live Mail has the additional ability to bounce back blocked e-mail to the sender and the ability to automatically unsubscribe the user's e-mail address from blocked mailing lists. Neither option is enabled by default and we agree with the decision as enabling both of these options may lead to more unsolicited e-mail.

The author of this chapter has never believed in country-specific blacklists because it means the potential e-mail receiver will never receive any legitimate e-mail from the blocked country either, and that can be a big risk to take for a business user. Who knows what legitimate, foreign friend you might make in the future? And months or years later, would you remember to remove the country-specific block when needed? However, many readers will probably enable country-specific blocks and immediately kill a huge portion of their spam, while not endangering any current e-mail contacts.

Another, more accurate feature is shown in Figure 10-12. Windows Mail allows messages encoded in foreign character sets to be automatically moved into the Junk e-mail folder. For example, if the reader does not understand Simplified Chinese character sets, all e-mail messages containing Simplified Chinese can be blocked by default.

Image from book
Figure 10-12: You may block messages using certain character encodings.

Of course, it would be very easy for a criminal, such as a phisher or spammer, to modify encodings, TLDs, and any other variable in a particular message. These blocking techniques are all highly insufficient as a comprehensive protection mechanism. At the end of the day, the only thing that will protect people from criminals is a highly developed sense of paranoia.

Simplified E-mail Storage

Windows Mail stores all e-mails in searchable *.eml files (see Figure 10-13). EML files are Multipurpose Internet Mail Extensions (MIME) formatted, file system-based text files. Each e-mail is stored as a separate file. This allows e-mails to be searchable, not only for indexing purposes, but to simplify the job of anti-malware tools. In previous e-mail clients, the various e-mail storage file formats complicated the job for protection products. Now, all content, malicious or not, can be searched and easily manipulated.

Image from book
Figure 10-13: Windows Mail stores all e-mail messages as text files.

Windows Mail has significant improvements in client-side security. Only time will tell how well Windows Mail stands up to years of constant attacks.


E-mail Defenses

This section covers the steps necessary to tighten computer security within any e-mail client.

Convert All E-mail to Plain-text

Unless you use e-mail clients that significantly restrict the permitted HTML tags and active content in HTML-based messages, all incoming and outgoing e-mail should be converted to plain-text, removing any potentially malicious HTML-enabled content. In many cases, this should be done regardless of the client. In Windows Mail, e-mails can be converted to plain-text when incoming, outgoing, or both. It is more important to convert all incoming e-mail to plaintext. Enable the Read all messages in plain text option, as shown in Figure 10-14.

Image from book
Figure 10-14: Windows Mail can convert all messages to plain-text.

Most corporate mail systems can also convert all mail to plain-text. When enabled, this type of feature will strip all non-plain-text content. In Windows Mail, it also attaches the original HTML content to the e-mail message as a separate .htm attachment (see Figure 10-15). Any arriving legitimate, HTML-enabled e-mail can be converted back to its original HTML content by launching the .htm file attachment.

Image from book
Figure 10-15: Windows Mail preserves the original HTML content as an HTML attachment.

Few, if any, corporate mail systems permit preservation of the HTML content in the way Windows Mail does, and it is questionable whether this is desirable in the first place. In most mail clients, conversion to plain-text is a one-way operation.

Although not as important as disabling inbound content, a user can also disable any non-plain-text content on outgoing e-mails. Enable the Plain Text options, as shown in Figure 10-16.

Image from book
Figure 10-16: You can also use plain-text for all outgoing messages.

You might wonder why this option is needed, as if the user would be creating and sending their own malicious content. Malware writers have created e-mails that launch their malicious content only when replied to. The inbound e-mail contains scripting that is activated only when the user replies to the message. The malicious e-mail will contain a legitimate social engineering-enabled message that induces the receiver to respond. For example, it may claim that the user's check has bounced against some unknown online auction. Unsuspecting users may reply to tell the sender that they are mistaken. When the user replies, the malicious content gets activated. This allows the attacker to potentially bypass inbound content removal mechanisms, and still give them a chance to activate malicious code during the reply.

Execute All HTML Content in the Restricted Zone

If HTML content must be displayed in e-mail, make sure it is rendered in Internet Explorer's Restricted zone. By default, as shown in Figure 10-17, all e-mail content is displayed in Internet Explorer's Restricted sites zone.

Image from book
Figure 10-17: Ensure that your mail client reads all mail in the Restricted sites zone.

This is also the default setting in Microsoft Outlook as well, and should be set as the default in any e-mail client. In fact, it should not even be an option that can be modified. By default the Restricted sites zone disables most active content, including scripting, ActiveX controls, and other binary objects. In order to change the behavior of rendered content in an e-mail, the user would have to modify the security permissions set in Internet Explorer for the Restricted sites zone or choose to enable the Internet zone as Windows Mail's default security zone (not recommended). Also, as shown in Figure 10-17, Windows Mail has a configuration option that allows the user to be warned if malware programmatically attempts to send e-mail out in an attempt to infect more e-mail recipients. This option attempts to prevent many types of e-mail worms and viruses, although these days most e-mail malware comes with its own built-in e-mail engines.

Disable Automatic Downloading of HTML Content

Spammers often include a link to a small, 1-pixel, transparent graphic file (called a web bug) that is quickly, and "silently" downloaded in the background when a spam e-mail is opened. The referenced file is uniquely named for each e-mail sent out by the spammer. When an affected user opens the spammer's e-mail, if the user's e-mail client downloads the referenced picture, the user's e-mail address is confirmed as a valid address (and potentially exploitable). The spammer then sends the user a lot more spam and sells the now verified, active e-mail address to other criminal and unsavory types.

Windows Mail defeats web bugs by refusing to download referenced content. The "Block images and other external content in HTML e-mail" option (as shown previously in Figure 10-17) prevents Windows Mail from downloading any externally referenced content.

Remote attackers can even place the web bug on a rogue Internet Information Service (IIS) server and require client authentication. In early versions of Internet Explorer on non-Windows NT-based platforms, (prior to IE 5.5), the e-mail client would silently transmit the user's current logon name and password to the remote Web site, where it was recorded. Now, Microsoft e-mail clients and Internet Explorer only automatically transmit the user's logon credentials in local intranet Web sites. As Figure 10-18 shows, Internet Explorer's Restricted sites zone, where HTML e-mail is rendered by default, will always prompt the user for their logon name and password any time it is requested. This default can be modified, although it should be left alone in most cases.

Image from book
Figure 10-18: For sites and e-mail messages in the Restricted Sites zone, the user is prompted for her username and password.

Filter Out Dangerous File Attachments

All potentially dangerous file attachment types without a legitimate business purpose in the organization should be blocked by default. Earlier in the chapter, Table 10-1 listed over 200 file extensions that have, or could be, used maliciously in Windows. To secure e-mail, all file extensions not expressly approved for legitimate use in the environment, should be blocked by default (i.e., a block-by-default rule). Which extensions are included should be guided by the organizational risk management strategy.

Unfortunately, Windows Mail and Microsoft Exchange Server do not allow file extensions to be blocked-by-default easily. Instead, a block-by-exception mechanism is used. The "Do not allow attachments to be saved or opened that could potentially be a virus" option (shown previously in Figure 10-17) will prevent 44 high-risk file types from being made accessible in Windows Mail, using the Attachment Manager (AM) functionality first shipped in Windows XP Service Pack 2.

By default, AM blocks the following file extensions:

  • .ade

  • .adp

  • .app

  • .asp

  • .bas

  • .bat

  • .cer

  • .chm

  • .cmd

  • .com

  • .cpl

  • .crt

  • .csh

  • .exe

  • .fxp

  • .hlp

  • .hta

  • .inf

  • .ins

  • .isp

  • .its

  • .js

  • .jse

  • .ksh

  • .lnk

  • .mad

  • .maf

  • .mag

  • .mam

  • .maq

  • .mar

  • .mas

  • .mat

  • .mau

  • .mav

  • .maw

  • .mda

  • .mdb

  • .mde

  • .mdt

  • .mdw

  • .mdz

  • .msc

  • .msi

  • .msp

  • .mst

  • .ops

  • .pcd

  • .pif

  • .prf

  • .prg

  • .pst

  • .reg

  • .scf

  • .scr

  • .sct

  • .shb

  • .shs

  • .tmp

  • .url

  • .vb

  • .vbe

  • .vbs

  • .vsmacros

  • .vss

  • .vst

  • .vsw

  • .ws

  • .wsc

  • .wsf

  • .wsh

All of these file extensions are considered Level 1 or high risk files.

If Windows Mail is being run in the Restricted zone (the default) the user will not be able to access any high-risk file (see Figure 10-19). If Windows Mail is being run in the Internet zone, the user will be warned and prompted prior to executing any high-risk file.

Image from book
Figure 10-19: By default, the user will not be able to access high-risk file types.

The user or administrator can also use group policy to modify the list of high-risk files, define moderate and low risk files, and implement other file attachment parameters. To modify Vista's file attachment treatment, use a group policy object or local computer policy (Gpedit.msc) to navigate to User Configuration\Administrative Templates\Windows Components\Attachment Manager (see Figure 10-20), and look for the settings starting with the words Inclusion list.

Image from book
Figure 10-20: An administrator can modify the behavior of the AM using Group Policy.

You can add file extensions to the high, moderate, and low file types. When you do this, any program that uses the AM, such as Windows Mail and Microsoft Outlook, will act on that file. If left alone, the 40 or so files listed previously are placed in the high-risk file types.

File types placed in moderate-risk setting can be opened in Windows Mail, but the user will be warned. File types listed in the low-risk setting will not prompt the user in Windows Mail. If any file type is listed in the moderate- or low-risk file types is identical to the default high-risk file types, the more specific setting applies (although file types listed in moderate override any conflicts in the low-risk area). However, any files listed in the high-risk area will override any conflicts in the moderate or low risk setting area. File attachment blocking can also be configured in Microsoft Exchange and Outlook (http://www.support.microsoft.com/kb/837388).

There are other important settings in the Attachment Manager container that an Administrator should review and configure. Referring to Table 10-1 as a starting point, identify the file attachment types in your environment that are medium and high risk. Then use group policy to configure the appropriate attachment blocking policy.

Install Anti-Malware Software

Anti-malware software should be installed in most environments. Defenses should include an antivirus scanner, an anti-phishing product, and an anti-spam filter. Additional defenses can be included as desired. Anti-malware software can be run on the client, on the e-mail server, on a perimeter gateway device, or on the incoming e-mail traffic using an external application service provider (Messagelabs, Postini, and so on).

Disable Plain-Text Passwords

Many e-mail clients, including Windows Mail, will transmit a user's password in plain-text when using SMTP or POP3 connectors (as shown in Figure 10-5 earlier). You can configure Windows Mail (or Outlook or Outlook Express), to protect (i.e., encrypt) passwords by enabling the "Logon using Secure Protected Authentication" option. If possible, use SSL/TLS-enabled protocols instead of plain-text POP, IMAP, RPC, and HTTP. Windows Live Mail also has authenticated POP (APOP).


Summary

E-mail has been the frequent target of malware writers. Malicious e-mail attachments, embedded content, rogue URL links, and other techniques have been used to exploit clients. Users can take many steps to significantly improve their e-mail security. Defense steps, including converting all e-mail to plain-text, running dangerous content in the Restricted zone, blocking dangerous file attachments by default, protecting passwords, and enabling anti-malware software.

Chapter 11 covers Windows Vista's much-improved Windows Firewall.


Best Practices

  • Analyze and understand your organization's risk management philosophy, or, if you are doing this for your own use, your own risk management philosophy.

  • Develop an e-mail policy that is consistent with the risks you are willing to accept.

  • Ensure that your anti-malware tools can handle e-mail messages and attachments.

  • Keep your e-mail clients patched.

  • Enable an allow-by-exception file attachment policy, if possible, or if not, block high-risk potentially malicious file attachments.

  • Convert all incoming e-mail to plain-text.

  • Disable all non-plain-text e-mail content.

  • Disable default picture downloading in e-mail.

  • Enable secure password authentication methods.

  • Disable unauthorized, unmanaged e-mail clients.

  • Enable antivirus software.

  • Enable anti-phishing features and/or software.

  • Enable anti-spam features and/or software.

  • Ensure e-mail client opens potentially malicious content in the Internet Explorer Restricted sites zone.

  • If using Windows Mail, download and install Windows Live Mail to get the increased functionality and security features.


Part IV: Securing Windows Networks

Chapter List

Chapter 11: Managing Windows Firewall
Chapter 12: Server and Domain Isolation
Chapter 13: Wireless Security


Chapter 11: Managing Windows Firewall

Overview

When Windows XP was introduced in 2001 it included a feature called Internet Connection Firewall (ICF). Unlike the TCP/IP Filtering that was included in prior Windows releases, ICF was a stateful, packet filtering firewall. It even blocked unsolicited SYN-ACK packets, but that was pretty much where its benefits stopped. To be fair, at the time, it was roughly at the stage where other host-based firewalls were, but it certainly was no leap forward.

Among the many shortcomings of ICF were:

  • Lack of central management

  • Single-profile-no separate settings for different networks

  • Not on at boot

In Windows XP Service Pack 2 (SP2) some of these shortcomings were addressed, and the Windows Firewall in Windows XP SP2 still is one of the lowest overhead, most reliable, and least intrusive firewall products available for Windows XP. In spite of this, it was still lacking a few features:

  • Limited integration with IPsec, including separate management interfaces

  • Strict source address mapping

  • ACLs on TCP and UDP ports

  • Outbound filtering

  • Extensibility

  • Support of more than two profiles

  • Scriptability

Image from book
WHAT IS A SYN-ACK PACKET?

The most common network protocol in use today is Internet Protocol (IP), with some transport protocol on top. The most widely used transport protocol is the Transmission Control Protocol (TCP). The remainder of this chapter assumes you have a working knowledge of TCP/IP.

When using the TCP protocol, computers establish sessions. This is done with what is known as the "three-way handshake." First, the client computer sends a hello message-a SYNchronize packet (a TCP packet with the SYN flag set). The Server then responds with an ACKnowledgement of the SYN from the client, and also sends a SYN of its own-a SYN-ACK packet. The client then responds with an ACK of the server's SYN, and we have a session.

The SYN-ACK is supposed to be sent in response to a SYN packet. Most firewalls are stateful and, therefore, keep track of all outgoing SYNs so that they know which incoming SYN-ACKs they should expect. However, in the early days of host-based firewalls quite a few did not track this. Attackers (often through innocent third-parties) use unsolicited SYN-ACKs for several things, but primarily Denial of Service (DOS) attacks. Processing an unsolicited SYN-ACK can be expensive, and this can cause performance problems on the victim.

Image from book

The firewall in Windows XP SP2 provided acceptable functionality and quite adequate security for the vast majority of organizations. Many organizations, still, purchased third-party firewalls (often to obtain features that they eventually turned out not to use and which often provided little or no security value, such as outbound filtering). To address the demand for additional features, Microsoft launched a massive overhaul project for the firewall in Windows Vista.

Image from book
WHY DO YOU NEED A FIREWALL?

Everyone should have a firewall on their computer. It certainly will not stop everything. But, it will protect you both against accidental exposures and programming mistakes by programmers who did not entirely practice the type of defensive programming required when you are writing programs that take network input. Such programs are far more complicated than purely local programs. As Alun Jones, author of the WFTPD FTP server, says: "Network programming is the hardest kind of programming because you're only writing half the program, and the guy writing the other half hates you."

Image from book


New Features

The firewall in Windows Vista is a completely different beast. It is actually just one possible implementation on top of a comprehensive, extensible filtering platform; an implementation that happens to have a lot of useful features. This is an important distinction as much of the work really went into the underlying platform not the firewall itself. To understand just how fundamental these changes are, we will look at the new features, starting with the Windows Filtering Platform (WFP) that underlies the firewall itself.

Windows Filtering Platform

WFP is the underlying filtering platform used by the firewall. To understand how it works, we show a block diagram in Figure 11-1.

Image from book

(source: http://www.msdn2.microsoft.com/en-us/library/aa366509.aspx)
Figure 11-1: The architecture of the Windows Filtering Platform

As Figure 11-1 shows WFP has both kernel mode and user mode components, and permits easy filtering at both layers. Previously, firewalls would have to perform some odd hooking tricks to see traffic before it got too far up the stack. The actual user interfaces (UI) for the new Windows Firewall are on top of the picture, in user mode. (Note that the picture refers to it as "Windows Personal Firewall UI." That was the old name used during development. It is now called simply "Windows Firewall UI.") Underneath that we see the base filtering engine. The filtering engine stores its configuration data in registry. The figure also shows several user mode filters. Those are used to filter application traffic, such as RPC.

We also see a filter engine in the kernel. Both native features and third-party tools can register callout functions with the filter engine. These will be called when certain events occur, at which point they can inspect the traffic and decide to take action on it. The action they take can block, or conditionally block (as long as no other filter specifies to definitely allow), or allow, or even modify the traffic. For instance, as the picture shows, a third-party antivirus product could create a kernel mode filter callout that inspects inbound traffic for viruses, before the application that requested the data even sees it. This incredibly powerful functionality is what the Windows Firewall is using. The hope is that third parties will extend it further with new types of filters.

The filtering engine, as indicated previously, works at many different layers. For instance, a particular filter could ask for packets only at the network layer, or only at the transport layer, or only UDP packets. A filter could also ask for only the first packet in a connection, or for all packets at the application layer, using the new Application Layer Enforcement (ALE) filters mentioned previously. This enables Windows Vista, and by extension, Windows Longhorn Server, to very easily be extended with application layer firewall functionality. It is not at all inconceivable that third-parties could write stateful inspection filters for HTTP packets for Windows Vista, for instance. The new filtering architecture is extensible enough to support many new and interesting features and it only makes sense to provide these types of well-defined hooks to perform filtering.

IPv6

Note that Figure 11-1 includes IPv6 in the stack. The WFP includes filtering for IPv6 and consequently the Windows Firewall protects the IPv6 stack as well. This is critically important as IPv6 is enabled by default in Windows Vista. Regardless of which firewall product you use on Windows Vista, you need to ensure that it can handle IPv6 traffic as well.

Integration with IPsec

Another epiphany that must have occurred during the development of Windows Vista was when someone looked at IPsec and Firewall and thought "Hey, these really do the same thing."

Image from book
WHAT IS IPSEC?

IPsec is a backport of a protocol that is part of IPv6. It is also the most powerful network security technology available today; and the most underutilized. Stated simply, IPsec supports authentication and encryption of IP traffic. For instance, if you have a file server, but you only want certain computers to be able to access it, such as only those that are members of your domain, you can use IPsec to enforce this restriction. Likewise, if you have a database server in a data center that should only be accessed by a single web server, an IPsec filter will enforce this restriction for you. If you have two servers, across the Internet, that need to talk to each other, but nobody else is allowed to talk to either of them you can use IPsec to solve that problem too. In Chapter 12, we will take a deeper look at how to use IPsec to enforce Server and Domain Isolation.

Image from book

This is really simple, actually. A firewall defines over which ports traffic can pass into and out of a network or a computer. IPsec defines under which conditions that traffic may pass. It is a really natural extension of a firewall to use IPsec to further control traffic.

In Windows XP SP2, the firewall supported an "authenticated IPsec bypass" filter. The filter took a Security Descriptor Definition Language string that defined which group of computers were exempted from the firewall restrictions, all of them, and were instead subjected only to IPsec restrictions. You then had to build the IPsec rules to implement exactly the policy you wanted, which turns out to be non-trivial.

In Windows Vista, instead, IPsec filters can be configured directly in the firewall UI. When you build a firewall rule you can specify whether to require the traffic to be authenticated or authenticated and encrypted, as seen in Figure 11-2. Note, however, that you must still build a corresponding IPsec rule to specify how exactly the encryption and authentication happens. The IPsec filter is not created automatically when you create the firewall rule.

Image from book
Figure 11-2: When configuring a firewall rule, you can also configure IPsec.

This integration with IPsec is quite logical and reasonably done. If you have ever struggled with IPsec in earlier versions of Windows, you will find this an immense improvement. Still, we wish there was an integrated way to build both the connection and the security rules. We will come back to the topic of IPsec integration later in the chapter.

Stealth

The Windows Firewall has a stealth feature that is on any time the firewall is active. The stealth feature is used to combat a method attackers often use to portscan (see sidebar) through firewalls. If a TCP port on a host is listening and a remote computer tries to connect to it, the connection will result in a standard TCP handshake, and the portscanner will report an open port. However, if the host is not listening on the port, the host returns a TCP RST (reset) message to the host that tried to connect to it. If a firewall in front of the host is configured to let a port through, but the host behind the firewall is not listening on it, the resulting reset tells an attacker that the firewall is configured to allow a particular port through.

The Windows Firewall in Windows Vista includes a stealth feature that blocks these RST messages outbound. If a message is sent to a UDP port or a non-TCP/UDP socket that is not listening, an analogous "nobody home" message is generated, and the firewall blocks these as well. This means that if the Windows firewall is allowing some traffic through and an attacker tries to portscan through the firewall, even if the firewall is configured to allow traffic to a port that does not have a service listening, the attacker will not see any indication of this.

Boot Time Filtering

One of the greatest shortcomings of ICF, and of virtually every third-party host-based firewall at the time and to this day, is the failure to protect the system at boot. One of the authors (Jesper) will never forget the moment, during the height of the Blaster worm outbreak in 2003, when some executives at Microsoft, extremely frustrated for understandable reasons, exclaimed that they could not understand how computers, unpatched as they were, which were demonstrably running with ICF enabled, could get infected. Jesper explained that it had to do with the lack of boot time filters. During the height of the Blaster worm outbreak in 2003, infection rates were running as high as one every four minutes. A computer at the time took about a minute or so to boot. The network interfaces went live early in the process, whereas the firewall, being a fairly high-level process, went live much later. The interval between when the network interfaces went live and when the firewall came up might be up to 20 seconds, or even more in some cases. With very simple math, we realize that a computer would get infected around one reboot in 12. Put another way, if you rebooted 12 computers, all running ICF, statistically one would get infected.

Image from book
PORTSCANNING

Portscanning is a very common reconnaissance technique used by attackers and network professionals alike. It simply consists of mapping out the remotely accessible network interfaces on a host. For TCP, portscanning is at the most basic level quite simple. The portscanner sends a TCP SYN packet to the host being scanned. If the host has a process listening on the target port, it will respond with a SYN-ACK and the portscanner can log this as an open port.

Portscanning can get significantly more involved than this, and can be varied in many ways to generate different information, to be stealthier, scan UDP and non-TCP/UDP ports, and so on. The interested reader is referred to the NMap reference guide: http://www.insecure.org/nmap/man/. NMap is one of the most popular portscanners and works on a wide variety of platforms.

Note that portscanning is NOT an activity undertaken solely by attackers. It can be an extremely valuable troubleshooting and monitoring tool for networking and security professionals. Anyone interested in becoming accomplished in either field should have a good understanding of how it works and when it can be useful. The mere fact that attackers use portscanning does not make the activity as a whole illegitimate. In fact, what many host-based firewalls report as portscanning attempts are often completely legitimate connection requests. It is virtually impossible to distinguish a portscan by a competent attacker from legitimate connection attempts.

Image from book

To address this issue, boot time filters were added in Windows XP SP2. In Windows Vista, the boot time filters were implemented in WFP. When the computer boots, the following happens:

  1. Machine boots, with no networking active.

  2. The networking stack starts up and starts the WFP driver.

  3. The network goes live and the WFP boot-time filters are in effect.

  4. The base filtering engine (BFE) service starts and replaces the boot-time filters with persistent filters, stored in the BFE rule store.

  5. The Windows Firewall service starts and reads the current policy settings, determines the current profile, and allows additional traffic.

The boot-time filters and the persistent filters are identical. The main reason two sets of filters are used so that BFE can retrieve its filters from only one place. They both:

  • Block all unsolicited inbound traffic.

  • Allow inbound traffic from any loopback address.

  • Allow inbound ICMPv6 neighbor discovery. Neighbor discovery is used to map IPv6 addresses to medium access control (MAC) or Ethernet addresses, and hence performs the same function as the Address Resolution Protocol (ARP) in IPv4.

When Windows Firewall goes live, in Step 5, it applies additional filters which allow additional traffic, based on the current profile. The persistent filters, however, are still there while the firewall is enabled. Only if the firewall is disabled do the persistent filters disappear. This means that if, for any reason, the firewall service dies, the persistent filters are still there and block all inbound traffic. In other words, Windows Firewall is designed to fail closed! There are very few other software firewalls that actually have the ability to fail closed.

Strict Source Mapping

In UDP, and portless protocols, there are no session semantics, and hence it is difficult to prevent a third party from taking part in a session.

For instance, if host A sends a UDP request to host B, host A will accept responses from any host that can respond on the requested port and protocol within a certain time limit (typically 60 seconds). This is called "loose source mapping" (LSM).

In Windows Vista, Windows Firewall uses strict source mapping. That means that it maintains a table of UDP and portless requests, and in order for a response to be allowed through it must match not only the protocol and port (for UDP) but also the IP address used in the original request. This is what is known as Strict Source Mapping (SSM). It is an attempt to bring session semantics to protocols that inherently have none.

The Domain Name System (DNS) protocol, and certain other protocols as well, requires an exception to the SSM rule. With DNS it is possible that the request was forwarded to a different server and the response will go from that server directly to the client. In this case, the reply is not coming from the host the requestor originally sent the request to, and if SSM is used, the response would be dropped by Windows Firewall. To prevent this, DNS has a special exemption to permit LSM in the default firewall ruleset. However, this opens the computer up to an obvious attack whereby an attacker would listen to DNS requests and respond with malicious data before the legitimate DNS server gets a chance to. To stop that attack the DNS client in Windows Vista is configured only to accept DNS responses from servers in its DNS server list. In other words, it will accept DNS responses from any server in its DNS server list, regardless of which one it sent the query to.

Service Hardening and the Firewall

With Windows Service Hardening, as we discussed in Chapter 6, it is now possible to restrict ports based on services. For instance, a firewall policy might restrict the RPC endpoint mapper to only listen on port TCP 135, and not allow it to connect out on any other port.

Such a policy was impossible to enforce on Windows XP, with the built-in firewall and with any third-party firewalls. Even if a firewall were to attempt to detect which process was accessing the port, this was trivial to circumvent. The process would simply find another process that was allowed to do what the malicious process wanted to, and which was running in the same service context. It would then hook the service with a debug API, inject whatever code it wanted into it, and the other service would then do the malicious process' bidding. In Windows XP, any process can debug any other process running in the same user context. That meant that keeping a compromised service running with a system account isolated was impossible. With 69 services running as LocalSystem by default, it was trivial to find some process that could do what you wanted. Of course, if a process is running as LocalSystem, it is omnipotent on the computer, under Windows XP.

In Windows Vista, this is no longer the case because of Service Hardening. With Service Hardening, the ACL on a process can include the Service SID and the RESTRICTED SID. As long as the process token of the malicious service, which presumably is one that has been hacked, is a restricted token using the service SID as the restricting SID, it will not be able to debug the victim process unless its restricting SIDs grant it permission on the victim process. In other words, taking over another process to do the evil bidding of a compromised process just got a lot more complicated. This means that ports can meaningfully be restricted to specific processes, as long as those processes are pre-configured with the right ACLs.

IPv6

Windows Firewall supports something that is currently, unfortunately, unique among host-based firewalls: IPv6. As you probably know, IPv6 is the long-awaited replacement for the current IPv4, which is the network protocol underlying the entire Internet today. IPv6 is not only supported in Windows Vista, it is installed, and even turned on, by default.

IPv6 changes significantly how we think about networking, but as far as firewalls are concerned, the first thing that changes is that you have to consider what happens when IPv6 is encapsulated in IPv4. The Windows Firewall is designed to handle that, as well as putting restrictions on native IPv6 traffic.

Outbound Filtering

More than any other feature, the lack of outbound filtering in the Windows XP SP2 firewall was held out as proof positive of why it was inadequate for security. The number of articles written about how insecure it is to use the Windows XP SP2 firewall because of its lack of outbound filtering must number in the thousands. This is in spite of the fact that no firewall on Windows XP could securely provide outbound filtering. The fundamental functionality that turns outbound filtering from a mere speed bump into a useful security feature-Service Hardening-simply does not exist in Windows XP. It does exist in Windows Vista.

Without service hardening, outbound filtering is useful only as a friendly suggestion that the end user might want to avoid certain destructive behavior. Any program executing on the computer can send outbound traffic on any port to any host. Service hardening changes that, and enables the Windows Vista firewall to provide meaningful outbound filtering. By default, most inbound traffic is blocked, and most outbound traffic is allowed, but many services have outbound traffic restricted by default.

Outbound filtering in Windows Vista is designed for two purposes:

  • Filtering of outbound connections for services.

  • Pin-point filtering of specific types of traffic by administrators, such as blocking outbound SMB traffic in the public profile, as we discuss later.

These are the two types of outbound filtering that actually provide useful security value, although a user running as an administrator, or code running on that user's behalf, can easily undo either or both of them. In making this design decision, Microsoft has taken the quite reasonable, and possibly even admirable, approach not to take the same path that virtually every other firewall vendor has taken.

How Much Security Can Outbound Filtering Provide?

Windows Vista blocks unnecessary/undesirable traffic originating from many services by default. Many articles in the popular press have already decried the fact that outbound filtering is off by default in Windows Vista. Those articles are, as you might expect, wrong. Not only is outbound filtering on by default, but there are 82 default filters that prevent 34 services from communicating out other than on a very narrow set of defined ports.

There is no GUI to configure the default filters. The filters are not actually even visible in the GUI. Currently, the main management interface is the COM scripting tools. For read-only purposes the default filters are listed in the registry, at HKLM\System\CurrentControlSet\Services\SharedAccess\ Parameters\FirewallPolicy\RestrictedServices\static\system.

Please note, however, that this registry location should be considered undocumented and can change. You should not edit the filters directly in the registry. Use the COM scripting interfaces, if you believe you need to modify them.

A matter of significant misunderstanding in the security community is how much security value can be had by outbound host-based firewall filtering. We have mentioned two scenarios so far that provide security through outbound filtering, but both rely on new functionality in Windows Vista that has not been previously available. In spite of this, there is a general perception that outbound filtering is general goodness, and should be used by everyone, even on operating systems prior to Windows Vista. It is also believed that it should drive firewall purchasing decisions. This is misguided and leads to a waste of money and effort from the security team.

These arguments are fueled by the fact that many firewall vendors have chosen to attempt to mislead customers by greatly hyping and overstating the value of outbound firewall filtering. No firewall can discern program intent. Also, a firewall cannot conclusively retrieve the name of the host the connection is going to. Therefore, when a firewall prompts a user to accept or deny a connection, the prompt typically looks like this:

         Program foo attempted to connect to port 48734 on 2001:0:4136:e388
     :244c:96e:3f57:7cb3. Do you wish to allow this?

The user has very little chance of making an intelligent decision based on that information. The Windows Vista Firewall does not present any popup dialogs for blocked outbound filters. The two usage scenarios Microsoft focused on do not require user consent; nor is it even desirable. Unfortunately, Microsoft is apparently not as coordinated as one might hope, nor as well informed in all the different groups. Contrary to the quite reasonable design implemented by the Windows Vista team, the Live OneCare team has taken the exact same approach as all the other firewall vendors. They built a firewall that asks the user to make important security decisions at runtime, typically based on data that does not provide sufficient information to enable the user to make an intelligent decision.

There is a very simple fact about generalized outbound filtering that its proponents fail to take into account. Their argument usually goes that if a system is compromised, whether by a worm or by an interactive attacker, outbound filtering will stop the worm from infecting other systems, or stop the attacker from communicating out. This is simply not true. What is true is that outbound filtering, all else being equal, would have stopped some historical malware. However, if Windows XP had come with outbound filtering, the worms we have seen so far would have simply been written to turn it off. On Windows XP and below, any worm that runs as a privileged service, which all the worms that come up in conversation did, could have done so. The only reason they did not is that there were simply not enough environments that used outbound filtering.

Outbound filters also do not help in an interactive attack, where the attacker can react on the fly to how the system is configured. In an interactive attack, the attacker can circumvent outbound filters at will. If the attacker has the ability to run arbitrary code, this is easy, but if necessary, the attacker can also lure the user into circumventing the filters by presenting a sufficiently enticing dialog box.

Figure 11-3 shows the dialog box a user would get when an application attempts to establish an outbound connection. It is an undoctored screenshot of what happened with a very popular personal firewall product when we tried to make an outbound connection using the very popular tool netcat. Of course, the statement that "nc.exe is attempting to connect to a DNS server" is based entirely on the connecting port number. The prompt would be the same if I had a different service listening on port 53 UDP.

Image from book
Figure 11-3: Dialog box that a user might see when an application tries to connect out

Look closely at the dialog box in Figure 11-3. Not only would the vast majority of users have no idea how to respond to this prompt, the default action is to "Always allow connections from this program on all ports." If the user were to simply click OK, as just about anyone would (because a connection to a DNS server is generally benign), the firewall would create a rule that allows this program to always connect out. In this case, the user would not ever see the next dialog box, shown in Figure 11-4.

Image from book
Figure 11-4: The user will almost certainly never see this dialog box.

The dialog box in Figure 11-4 is the one that actually tells the user, or rather, the small percentage who know how to decipher it, what is actually happening. By attempting a largely benign connection initially, the user would be tricked into the default action of always allowing the program. After that formality is over the program can proceed and take the actually malicious action. A truly malicious program could obviously take advantage of that. Furthermore, what exactly is it that the firewall considers malicious about connecting to port 80? The program may be retrieving a cool game, checking the local time, or uploading a list of all your credit card and bank account numbers. As mentioned earlier, no firewall can discern program intent.

The dialog box in Figure 11-3, and even the one in Figure 11-4, is emblematic of a much bigger problem: the computer industry has done an extremely poor job of giving users information they can use to make intelligent security decisions. Imagine that your users can't think of anything more important than seeing naked dancing pigs. Consequently, they spent all morning searching BitTorrent, The Pirate Bay, and Morpheus for various (malicious) programs that show naked dancing pigs. Given the choice of naked dancing pigs, and some obtuse, incomprehensible dialog box espousing an unstated security benefit that the user is not given any information to understand, the user will with near 100 percent probability select the certain benefit of the naked dancing pigs. Particularly because if the user has used the computer for any more than about 37 seconds with the outbound firewall turned on, the user will have been so inundated with these dialog boxes that they have become nothing more than a fast-clicking exercise standing in the way of the proverbial "naked dancing pigs." This is the number one problem with outbound filtering.

Presenting dialog boxes asking for security decisions with sufficient information to base that decision on is much harder than it sounds because it would require the firewall to not just understand ports, protocols, and the application that is making the request, but also to understand what it is the request really trying to do and what that means to the user. This information is very difficult to obtain programmatically. For instance, the fact that Microsoft Word is attempting to make an outbound connection is not nearly as interesting as what exactly Word is trying to do with that connection, but you do not know that upon connection establishment.

We need to reduce the number of meaningless dialog boxes, not increase them, and outbound filtering firewalls do not particularly help there. While writing this chapter, we went and looked at the sales documentation for a major host-based firewall vendor. They tout their firewall's outbound filtering capacity and the new advising capability, purported to give information to the user to make intelligent security decisions. In the product glossy, there is even a screenshot that proudly proclaims, "Advice is not yet available for this program. Choose below or click More Info for assistance." Below that are two buttons with the texts "Allow" and "Deny." It seems that even in the marketing material, the vendors cannot produce informative dialog boxes.

The fact that users do not possess sufficient information to make the right security decisions means that it is incumbent on the administrator to configure all outbound filtering because the end user will not be able to. This increases the administration burden of the administrator infinitely. It is virtually impossible to develop a reasonable set of outbound restrictions unless we have multiple firewall profiles, and are willing to make very broad generalizations that may impact functionality for many users.

The second problem with outbound filtering is that even if the user, for some inexplicable reason selected the "No. Bug me again" option in the dialog box (also known as "Block this program"), the malware can attempt to step right around the firewall. In Windows XP, where every process running in a particular user context had full access to all other processes running as the same user, this is trivial. As long as that user can open outbound connections on any port the evil code can simply use that port. Even if the firewall limits connections to a certain process, the kernel functionality to truly enforce this does not exist on Windows XP, only on Windows Vista. This allows any process to piggy back on an existing process that is allowed. Of course, in Windows Vista, the processes can be suitably restricted, which is why services are blocked using the outbound filters by default.

The key problem is that most people think outbound host-based firewall filtering will keep a compromised asset from attacking other assets. This is impossible. Putting protective measures on a compromised asset and asking it not to compromise any other assets simply does not work. Protection belongs on the asset you are trying to protect, not the one you are trying to protect against! Asking the bad guys not to steal anything after they have already broken into your house is unlikely to be nearly as effective as keeping them from breaking into the house in the first place.

This, of course, holds unless the objective is simply policy enforcement, meaning attempts to stop non-malicious processes from accidentally communicating out. That is basically what we will do later when we show you how to block SMB outbound in the public profile. However, unless you have access to multiple profiles doing those types of things becomes impossible. It is only meaningful to block outbound SMB when the computer is off the organizational network. If you do so when it is inside the organizational network the computer becomes only marginally useful. Besides, if you can make general blocks across profiles you do not need an outbound filtering firewall. That functionality is available in Windows XP through IPsec.


Firewall Management

Firewall management with Windows Vista will require some thought. Not only do you need to think about what you want to accomplish, but there are several different interfaces, and it is not always intuitive which one you should use. In this section, we will try to resolve some of the confusion and explain how to manage the firewall in various scenarios. In Chapter 12, Domain Isolation, we talk about a specific type of deployment that would be well worth considering.

Firewall Profiles

One of the main complaints over ICF was that you could not configure the system to behave differently if the computer were inside the corporate network versus if it were not. In Windows XP SP2, Microsoft "borrowed" a concept that many other personal firewalls were already using and introduced firewall profiles. In Windows Vista this concept is further extended. This is probably the first thing users notice about the firewall because already during setup they will be asked to select a firewall profile for the current network, as shown in Figure 11-5.

Image from book
Figure 11-5: During setup, you have to select a firewall profile.

The two profiles in Windows XP SP2 were the domain profile and the standard profile. The domain profile was automatically invoked when the computer could find a domain controller; otherwise the standard profile was used. This functionality gave powerful control for a security administrator. It meant that the system could be locked down completely when the user was roaming, while still allowing all the remote management functionality needed on the organizational network. However, it presented certain problems for some users, notably those that had networks at their homes, but without a domain. Since the standard profile was always used if the system was unable to reach the domain controller, it means the system would be locked down also from computers at the user's home.

Windows Vista resolves this issue by introducing a third profile: the private profile. Both the Home and Work profiles in Figure 11-5 actually map to the private profile. The Domain profile is not shown in the dialog box because it would be automatically selected if the computer can reach a domain controller. The Public location maps to the public profile, which has taken the place of the standard profile from Windows XP.

When you connect the computer to a new network, it will ask you whether that network is public or private and configure the system appropriately. It remembers this selection each time you connect to that network, based on network parameters presented to it by the infrastructure servers on the network.

This is not foolproof functionality by any means, but it does help. It is now possible to have a public profile that turns the computer into a black hole, while still allowing users to have some networking functionality at home. We have one big concern with this though.

The problem centers on the connotation of the word "home." As you can see, the dialog box in Figure 11-5 does not exactly give the user a lot of information on how to make an intelligent security decision. Far too many users still have no firewall in their house, or it is not configured properly. It does not take much to imagine a Holiday scenario where a user plugs his shiny new Windows Vista computer directly into his cable modem. Windows Vista comes up and asks what type of network it is on. The user looks around, sees the dog eating the couch, big brother tugging at little sister's hair, grandmother pouring brandy into her egg-nog,, and grandpa hard at work breaking junior's new train set. With a big sigh, the user clicks Home and opens his shiny new computer to the big bad Internet, when the appropriate option would have been Public.

By default, all networks are in the public profile until the computer is configured otherwise, or until a domain controller is detected. Manually setting the profile to anything other than public requires administrative privileges.

The detection logic for whether the system is on the domain has been much improved. There is a new Network List Service (NLS) which is integrated with Network Location Awareness (NLA). It notifies the firewall each time NLA detects a change in the network. This results in a faster and more reliable transition. The transition happens within 200 milliseconds of a change in network status. The net effect is that fewer computers are using the public or private profiles when they are actually on the domain.

A common question is what happens if a host is connected to the domain with only one of several interfaces, or more generally, what if two interfaces in the host are on different network categories. The profiles have a precedence order based on which is considered to be more restrictive. The order, from least to most restrictive, is domain, private, public. Thus, let's say a computer has two network interfaces. One of them can see the domain controller. The other interface can not see the DC, nor has it been assigned to a private network. The second interface would therefore be in the public profile, and in this case the firewall will use the public profile for all interfaces. This behavior holds even if the computer is on a VPN connection. The most restrictive profile would still be used. Therefore, if you wish to allow certain traffic into the computer when it is connected via VPN, you must create rules in the public and private profiles that apply only to VPN interfaces. We will discuss that in more detail later.

Management Interfaces

Management of Windows Firewall has become much more complex with all the new features. Perhaps the biggest complication is that there are a number of new management interfaces available. In this section, we briefly introduce each of them. In later sections, we show how to manage the firewall with them.

Windows Firewall Control Panel

The Windows Firewall control panel, shown in Figure 11-6, is the simplest of the interfaces. It enables you to see the current configuration of the firewall and also presents links on the left that enable you to do basic management.

Image from book
Figure 11-6: The Windows Firewall control panel

The Windows Firewall control panel allows non-administrators to very quickly see the status of the firewall. However, any modification of the firewall requires administrative privileges,. This is evident from the presence of the little shield icon on the links. All three links (Change settings, Turn Windows Firewall on or off, and Allow a program through Windows Firewall) open the Windows Firewall Settings dialog box, shown in Figure 11-7.

Image from book
Figure 11-7: The Windows Firewall Settings dialog box

The Windows Firewall Settings dialog box is almost identical to the Windows Firewall control panel in Windows XP. Some of the language has changed, and on the advanced tab the Security Logging, and ICMP settings are gone.

The Windows Firewall control panel is primarily used for very simple operations and is really designed for home users to see a quick overview of the state of the firewall. It only shows settings for the currently active profile, for instance. While you can add basic rules in the control panel, we recommend you use a more powerful and flexible interface. You really get the feeling after a while that the Windows Firewall control panel primarily exists because people are familiar with using it. It no longer provides any compelling functionality.

Security Center

Security Center, shown in Figure 11-8, provides similar information to the Windows Firewall control panel. It is also designed primarily for home users, but gives a better overview of the aggregate security state of the system.

Image from book
Figure 11-8: Windows Security Center

The Security Center uses the new style for control panel applets and presents links to related options in the left-hand pane. If you click the Windows Firewall link, you get to the Windows Firewall control panel.

We should note that the reason the malware protection status in Figure 11-8 is yellow is that the system in the screenshot is an almost completely clean installation of Windows Vista, which does not come with an antivirus program. We do not necessarily recommend that you keep it that way.

Windows Firewall with Advanced Security

The most powerful of all the interfaces for managing Windows Firewall is the Windows Firewall with Advanced Security MMC snap-in, wf.msc. It is available under the Administrative Tools folder and is the first time we really notice all the new features in the firewall. The introductory screen is shown in Figure 11-9. In subsequent sections, we take a deeper look at how to use this interface.

Image from book
Figure 11-9: Windows Firewall with Advanced Security snap-in

Group Policy Editor

The settings in the Windows Firewall with Advanced Security snap-in are also available in Group Policy. Figure 11-10 shows the first screen of the Group Policy interface in a beta copy of Windows Longhorn Server.

Image from book
Figure 11-10: Windows Firewall settings in Group Policy

For backward compatibility, the settings to configure the Windows Firewall in Windows XP SP2 and Windows Server 2003 Service Pack 1 (SP1) and higher are also present in Group Policy in Windows Longhorn Server. The root of those settings is shown in Figure 11-11.

Image from book
Figure 11-11: You can also configure the Windows XP SP2 firewall settings in Group Policy.

Unless you have Windows XP SP2 and Server 2003 SP1+ computers in your environment, you should not configure the older settings. Stick with the new ones. In the section on management in a mixed Windows XP and Windows Vista environment, we will look at how the interoperability works.

Netsh

Netsh is a command line tool that has been available in several versions of Windows now. Netsh operates on a menu-based principle with contexts that contain commands and more contexts. To launch netsh just type netsh at a command prompt.

There are several contexts that are related to the firewall:

  • advfirewall: This is the context used to manage the Windows Vista firewall. It allows you to manage the new features that were not available in Windows XP.

  • ipsec: This context allows you to manage IPsec rules. It existed also in Windows Server 2003, but not in Windows XP. The commands are the same as in Windows Server 2003.

  • consec: Connection security rules (also IPsec filters) are managed in the advfirewall consec context.

  • firewall: This context existed in Windows XP and Server 2003 as well. You can perform the same tasks in the "advfirewall firewall" context-but it is highly recommended that you do not use it! Rules set in the firewall context are configured using the old Windows XP SP2 mechanisms, and do not comply with the new profiles in Windows Vista. The firewall context is included primarily for backward compatibility with old scripts.

Nobody ever accused netsh of being a simplistic tool. It is quite complicated, and extremely powerful. The number of times you use it depends entirely on your management style, as there are numerous other tools, however, which can perform the same tasks. For good measure, we will use it later to configure a rule as a way to demonstrate what it can do.

Application Programming Interfaces

The firewall obviously comes with a set of Application Programming Interfaces (API) you can use to programmatically configure the firewall. These are primarily designed for third-party developers who need to configure the firewall to allow their programs, or who wish to provide status information on the firewall. However, they can also be used by administrators who are interested in the same type of features. You may, for instance, want to create a VPN logon script that queries whether the firewall is active or not, and turns it on if it is not. Here is a VBScript that will do that:

     'IsFirewallActive.vbs
     option explicit

     Dim CurrentProfile

     ' Create the FwPolicy2 object.
     Dim fwPolicy2
     Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

     CurrentProfile = fwPolicy2.CurrentProfileTypes

     if fwPolicy2.FirewallEnabled(CurrentProfile) <> TRUE then
         WScript.Echo("Windows Firewall is disabled.")
         fwPolicy2.FirewallEnabled(CurrentProfile) = TRUE
         WScript.Echo("WindowsFirewall is now on")
     else
         WScript.Echo("Windows Firewall is enabled.")
     end if

You may also want to find out which profile is active. Here is a sample VBScript that tells you:

     ' WhichFWProfile.vbs
     Option Explicit
     Dim CurrentProfile
     Dim Message

     ' The profiles are bitmasks with the following values
     Const NET_FW_PROFILE2_DOMAIN = 1
     Const NET_FW_PROFILE2_PRIVATE = 2
     Const NET_FW_PROFILE2_PUBLIC = 4

     ' Create the FwPolicy2 object.
     Dim fwPolicy2
     Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

     CurrentProfile = fwPolicy2.CurrentProfileTypes

     Message = "The following firewall profile(s) is/are currently active" + vbCrLf

     if(CurrentProfile AND NET_FW_PROFILE2_DOMAIN) then
            Message = Message + vbCrLf + "The Domain profile"
     end if

     if(CurrentProfile AND NET_FW_PROFILE2_PRIVATE) then
            Message = Message + vbCrLf + "The Private profile"
     end if

     if(CurrentProfile AND NET_FW_PROFILE2_PUBLIC) then
            Message = Message + vbCrLf + "The Public profile"
     end if

     WScript.Echo Message

Both of these scripts are available on the Web site accompanying the book. Full details on how to program to the Windows Firewall, along with many more samples, are available in the MSDN library, at http://www.msdn.microsoft.com/library/en-us/ics/ics/using_windows_firewall_with_advanced_security.asp.

Rule Types

There are several ways to categorize rules in the Windows Firewall. On the one hand, we have per-program rules versus per-port rules. On the other hand, we can distinguish between rules that filter based on ports, and those that filter based on other traffic parameters, such as which computer is on the other side of the connection. Historically, the former has been performed by stateful firewalls, although they could of course also put an IP address or a hostname into the rule as a way to restrict the traffic from going only to certain computers. However, an IP address is a very poor authentication token since it can be changed, or spoofed. A much better one is a digital certificate or other cryptographic authentication token. Rules that filter on those were the domain of IPsec until Windows Vista.

As mentioned earlier, the firewall and IPsec have now been combined. Within the Windows Firewall you can create standard firewall rules, which we will refer to as "directional rules" here (Microsoft calls them "firewall rules" but we find that term confusing since all rules are specified within the firewall). Within the same interface you can also create connection security rules that are used to limit connections to only particular hosts or even users. With the integration of IPsec and the firewall, you can control connections down to the individual user. Figure 11-12 shows the dialog box that controls this.

Image from book
Figure 11-12: Configuring the firewall to allow connections only from particular users

To get to this dialog box you would right-click the inbound rule you want, select properties, and then go to the Users and Computers tab. You can only configure authorized users on inbound rules and obviously only if you allow only authenticated traffic. Two additional items must also be present for peruser rules to work. First, you must have a connection security rule-or some other IPsec policy-that defines this traffic. Second, the IPsec rule must use credentials that carry Active Directory user information, such as Kerberos or certificates with a certificate-to-account mapping.

Directional Rules

You would normally configure directional rules in the Windows Firewall with Advanced Security, although you can configure them in the Windows Firewall Settings dialog box as well. The drawback of using the Windows Firewall Settings dialog box is that you give up control. For example, if you allow a program to listen, it allows the program to listen on any port, TCP and UDP, but only in the current profile.

With the Windows Firewall with Advanced Security interface you get tremendous control over the rules. This allows you to solve problems that were previously unsolvable. Later we will use the ability to permit traffic only over certain interface types to allow management traffic over a VPN connection.

The types of things you can do with directional rules are more or less what you would expect. You get full five-tuple configuration: local program, local address/interface, local port, remote address, and remote port. You also get the ability to bind an IPsec policy to the rule, allowing you to require authentication of the remote address and, optionally, encryption. If you elect to use authenticated traffic, the rule uses IPsec with Encapsulating Security Payload (ESP) but without an encryption key (ESP NULL). This saves processing time and permits you to use normal network monitoring tools to inspect traffic.

You may recall that there is an authentication header (AH) option on IPsec. However, AH cannot traverse network address translation boundaries and is opaque to most management tools. Therefore, it is rarely used.

Connection Security Rules

Connection security rules define the protection parameters for connections between computers. To draw an analogy, the directional rules are essentially your traditional firewall rules, whereas the connection rules, which govern encryption and authentication, are like the IPsec rules used in conjunction with the firewall in Windows XP SP2.

By combining the firewall with IPsec into the same interface several very interesting scenarios are enabled. One of the most valuable is the ability to isolate systems from one another and permit only the communications patterns you need in your network. Microsoft calls this Server and Domain Isolation. We will examine it in Chapter 12.

For some systems you cannot enforce authentication. For instance, for DNS resolution, you probably do not want to require authentication. For those systems, you need an authentication exemption rule. An authentication exemption rule is exactly what it sounds like-it exempts the traffic from IPsec requirements.

A server to server rule is a bit misnamed in the sense that it might be used with clients as well, although it is more commonly used with servers. It simply sets up the authentication parameters for a connection. This is different than an isolation rule. Not only does an isolation rule require authentication, it also requires fulfillment of some additional criteria, such as domain membership or health state.

Tunnel rules will likely be rarely used with Windows Vista. A tunnel rule defines a site-to-site VPN and is used to define the tunnel between the gateways. It is unlikely that Windows Vista will be used in a gateway capacity.

Finally, you can create a fully custom rule. Selecting this option gives you the ability to customize all the parameters of the rule.

When to Use Which Rules

Generally speaking, directional rules define which traffic is allowed. Connection security rules define how the traffic that is allowed is authenticated and/or encrypted. You typically use directional rules to permit the services you need and optionally specify authentication requirements on them. You use connection security rules to enable the authentication.

Rule Precedence

The rule precedence order is a bit complicated at first glance, but the key to understanding it is really to forget about ordering. It is really a matching issue, not so much ordering. Take inbound traffic, as an example. Inbound traffic is blocked by default if it does not match any rule that allows it. While you may consider this to be an ordering that says "Allow rules are considered first," that would be incorrect. If a specific packet is matched by both an allow rule and a block rule, the block rule has priority. That means that the ordering, simplistically, is as follows:

  • Block rules: If a packet or connection matches one of these, it is discarded.

  • Allow rules: If a packet or connection matches one of these, it is allowed.

  • Default directional profile behavior: If no block or allow rules match, the traffic is treated according to the behavior specified as the default for traffic in that direction in that profile. In the inbound direction in all profiles that means blocking the traffic in a default configuration.

You also have to add authenticated bypass (IPsec) rules to this, which allows authenticated traffic to always reach the system. This enables you to easily block traffic from unauthenticated hosts, while allowing it from everyone else. You can consider that rule 0, if you will. In other words, the complete rule order list is:

  1. Authenticated bypass rules

  2. Block rules

  3. Allow rules

  4. Default directional profile behavior

It does not really matter if there are multiple rules within each class that match the traffic pattern. As soon as any rule matches, processing stops and the traffic is allowed or blocked depending on the rule.

Firewall Scenarios

Now that we have gone over the basic management interfaces, we can look at some scenarios. We cannot cover all possible scenarios where you might want to use the Windows Firewall, but we can certainly go over a few common and valuable ones, demonstrating different functionality in the process.

Restricting Access Based on End-Point

The first thing you might want to do is to open up a port for only a particular host. For instance, maybe you are hosting a SQL Server, but you only want a particular middleware server to connect to it. You can build a rule to allow this a few different ways. One is to build a program rule-a rule that ties it to a particular program, SQL Server in this case. The other is to build a port rule-a rule that ties it to a particular port. Generally, if you can tie it to a program you are better off. The firewall will only open the port to that particular program, which means that if the program is not running, the port is closed. If the program is running, only that program gets to listen on the port. By contrast, when you open a port, the port is always open, regardless of whether you need it or not. The ability to restrict access to specific programs is one advantage of a host-based firewall.

To get started open the Windows Firewall with Advanced Security interface, click Inbound Rules, and click New Rule under the Actions. We are greeted with the dialog box in Figure 11-13.

Image from book
Figure 11-13: Building a program rule, Step 1

Select Program and click next. You now have to define which program you wish to apply the rule to, as shown in Figure 11-14.

Image from book
Figure 11-14: Enter the path to the program you wish to control.

We want to open a port for Microsoft SQL Server 2005, so we will enter the path to the executable for the default instance. Click next and you get asked whether you wish to use IPsec to authenticate the connection. We do, but we do not need encryption, as we are pretty certain the channel is secure and traffic cannot be intercepted and decoded. This is shown in Figure 11-15.

Image from book
Figure 11-15: We will require IPsec authentication.

Figure 11-15 shows only the directional rule that specifies whether we will accept the connection or not. In order for traffic authentication to actually take place, and for the traffic to actually be allowed in, we also need to create a connection security rule. We will do that later.

When you click Next you get to finally specify which computers, and optionally, from which users you wish to allow these connections, as shown in Figure 11-16.

Image from book
Figure 11-16: Restricting connections to certain computers

Keep in mind at the stage shown in Figure 11-16 that when you create the connection security rule, you must select an authentication method that contains the Active Directory account information for the objects you wish to allow. Generally, that means you have to use either Kerberos or certificates with a certificate-to-account mapping.

Click Next again and you get to decide which profile you wish to allow this traffic in. Since we are requiring IPsec authentication, there is no harm in allowing it in all three, as shown in Figure 11-17.

Image from book
Figure 11-17: Configure which profile the rule applies in.

When you click Next, you get to pick a name for the rule, and then you are done with the directional rule portion. Now you need to configure the corresponding connection security (IPsec) rule. To do so, start out by clicking Connection Security Rules in the left-hand pane and then click New Rule under Actions. You will get the dialog box, as shown in Figure 11-18.

Image from book
Figure 11-18: Create a server-to-server connection security rule.

You can use either a server-to-server rule or an isolation rule. The remaining steps are almost identical between the two. Let us pick a server-to-server rule to ensure that we cover all the bases. Select that and click Next. At this point you need to define the two end-points. We do not really care about the end-points in this case since we already specified them in our directional rule. All we really need to do is ensure that the computer will request IPsec authentication. Therefore, we leave the end-points as Any IP address, shown in Figure 11-19.

Image from book
Figure 11-19: Leave the end-points as "Any IP addresses".

We now need to select when we want the connection authenticated. We do not require all connections to be authenticated. We only want to enable authentication so we can restrict traffic as per our directional rule. Therefore, we select "Request authentication on inbound and outbound connections" in Figure 11-20.

Image from book
Figure 11-20: We want to request authentication.

Next, we get to select our authentication methods. We are in a domain environment, so we wish to use Kerberos. The authentication method dialog box, in Figure 11-21, does not include Kerberos as a choice. If we picked an isolation rule in Figure 11-18, it would have included Kerberos, but because we used a server-to-server rule we must customize the options, as shown in Figure 11-22.

Image from book
Figure 11-21: Click the Customize button to select advanced authentication protocols.
Image from book
Figure 11-22: Select Kerberos as your authentication protocol.

To use Kerberos, click the Customize button. This brings up a dialog box, as shown in Figure 11-22, where you get to choose which authentication methods you wish to use. Click Add in the first authentication method dialog box and select Computer (Kerberos V5). Click OK to close the dialog box.

You now click Next and select which profiles the rule is used in. Then save the rule and you are finished. It is a bit complicated, but if you ever tried to configure IPsec rules, and particularly IPsec rules in conjunction with firewall rules in older versions of Windows, you can surely appreciate just how radical a departure this new interface is. The IPsec configuration wizard in Windows 2000–2003 was virtually the poster child for user unfriendliness. The new wizards have some way to go, but are a very welcome change indeed.

Blocking Outbound SMB in Public Profile

The ability to tie authentication rules to a particular type of network prevents the system from volunteering too much information and trying to connect to systems on untrusted networks. This is really one of the areas where the integration of the firewall and IPsec starts paying off.

Using these new rules, you can also provide some restrictions that were not previously possible. For instance, for many years attackers have been attempting luring attacks to get users to make SMB (Windows networking) connections to untrusted hosts, thereby forcing an authentication sequence giving them a challenge response pair that can be used to crack passwords. Older versions of this attack were also used to downgrade to clear-text authentication, or to "reflect" the user's challenge-response pair back to the originating computer. The former attack was broken years ago, and the latter in Windows XP SP2, but volunteering challenge-response pairs is nevertheless unwise.

To prevent this, you could use another new function in the Windows Vista firewall-outbound filtering. An administrator could decide, for instance, to block all outbound SMB connections (those terminating at ports TCP 135, 139, 445, and UDP 137, 138, 445) in the public profile. This would prevent a computer from being accidentally used in a luring attack to gain challenge-response pairs. Again, this is certainly not foolproof functionality. For example, if the computer has already been compromised, this rule would not stop it from communicating out, as the attacker can simply disable the rule. However, as a measure that protects well-behaved but potentially exposed computers, particularly those with users prone to be easily lured into connecting to rogue sites, it could be useful.

Because we have already used the wizard to configure one rule, we will use the netsh tool to configure this one. The requirements are quite simple. We wish to block traffic destined for any computer on ports TCP 139, 445; UDP 137, 138, 445. For good measure we will also block RPC end-point mapper traffic, traffic going to port 135. To do this we use the netsh advfirewall firewall context, and the add command, which has this syntax:

     add rule name=<string>
           dir=in|out
           action=allow|block|bypass
           [program=<program path>]

           [service=<service short name>|any]
           [description=<string>]
           [enable=yes|no (default=yes)]
           [profile=public|private|domain|any[,...]]
           [localip=any|<IPv4 address>|
              <IPv6 address>|<subnet>|<range>|<list>]
           [remoteip=any|localsubnet|dns|dhcp|wins|defaultgateway|
              <IPv4 address>|<IPv6 address>|<subnet>|<range>|<list>]
           [localport=0-65535|RPC|RPC-EPMap|any[,...] (default=any)]
           [remoteport=0-65535|any[,...] (default=any)]
           [protocol=0-255|icmpv4|icmpv6|icmpv4:type,code|icmpv6:type,code|
              tcp|udp|any (default=any)]
           [interfacetype=wireless|lan|ras|any]
           [rmtcomputergrp=<SDDL string>]
           [rmtusrgrp=<SDDL string>]
           [edge=yes|no (default=no)]
           [security=authenticate|authenc|notrequired (default=notrequired)]

We actually need to run two commands. We can specify several ports, but not several port/protocol combinations, so we need one command for TCP and one for UDP. Here are the commands we run (note that the lines are wrapped):

     Netsh advfirewall firewall add rule name="OB SMB TCP" dir=out   Image from book
     action=block description="Block all outbound SMB and RPC traffic"   Image from book
     enable=yes profile=public localIP=any remoteip=any localport=any   Image from book
     remoteport=135,139,445 protocol=TCP interfacetype=any

     Netsh advfirewall firewall add rule name="OB SMB UDP" dir=out   Image from book
     action=block description="Block all outbound SMB and RPC traffic"   Image from book
     enable=yes profile=public localIP=any remoteip=any localport=any   Image from book
     remoteport=137 protocol=UDP interfacetype=any

It is important to reiterate in this context that just as in Windows XP SP2, only one profile can be active at a time. If there are two network interfaces live in the system and one of them is on the domain but the other is on a public network, the public firewall profile will be applied to all of them. This actually leads us to our next topic. We may want to modify these rules so they only apply to traffic over wired and wireless interfaces, but not VPN interfaces. Otherwise, they will significantly interfere with domain traffic while we are connected to a VPN.

Allowing Management Traffic via VPN

To modify our outbound SMB blocking let's use the GUI this time. Open Windows Firewall with Advanced Security and click Outbound Rules in the left pane. Highlight the OB SMB TCP rule and select properties. Click the Advanced tab and click the Customize button by Interface Types. You get the dialog box shown in Figure 11-23.

Image from book
Figure 11-23: Customizing a rule by interface type

We want the rule to apply only to wired and wireless interfaces, but not to VPN connections, so we uncheck the Remote Access dialog box. Click OK a few times, and then do the same with the OB SMB UDP rule.

Of course, the astute reader would argue that we could have saved ourselves this roundtrip into the GUI by simply modifying our netsh script as follows:

     Netsh advfirewall firewall add rule name="OB SMB TCP" dir=out   Image from book
     action=block description="Block all outbound SMB and RPC traffic"   Image from book
     enable=yes profile=public localIP=any remoteip=any localport=any   Image from book
     remoteport=135,139,445 protocol=TCP interfacetype=wireless, lan

This is, of course, correct. You can specify the interface type in Netsh too. We leave figuring out how to do this for the UDP rule as an exercise for the same astute reader.

Managing Firewall in a Mixed or Down-Level Environment

If you are in a mixed environment with down-level (that is, Windows XP SP2, or older unsupported clients, and/or Windows Server 2003 servers), there are a few special considerations for managing the firewall, mostly to do with how to get the proper set of policies to apply to both Windows Vista and down-level systems. The most common problem in this type of environment is that the Windows Vista systems end up without a firewall running at all. Many organizations have purchased a third-party personal firewall, and have consequently configured Group Policy to turn off the Windows XP SP2 firewall. This is done using the legacy firewall settings shown previously in Figure 11-11.

If there are no Group Policy settings made in the Windows Firewall with Advanced Security section, the settings in the legacy node will take precedence and Windows Vista will configure its firewall as per these settings. In an environment where you were using a third-party firewall on Windows XP, but you wish to use the built-in firewall in Windows Vista, this results in Windows Vista being unprotected.

To further complicate this issue, there is no precedence order for this setting. Consider the following scenario.

  1. Use the down-level settings, shown previously in Figure 11-11, to disable the Protect all network connections setting in the domain profile.

  2. Then use the Windows Vista interface, shown previously in Figure 11-10, to turn on the firewall in the domain profile.

  3. Force a group policy refresh on a member system. You will find that the firewall is turned on in the domain profile on all systems, regardless of operating system.

  4. Check the setting for the Protect all network connections setting in the down-level area. If you have closed and reopened the group policy editor after Step 2 it will say "enabled," otherwise it will say "disabled."

The two interfaces actually configure the exact same setting. In fact, if you check the values in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall, you will find four profiles there: DomainProfile, PrivateProfile, PublicProfile, and StandardProfile, assuming you have configured all four. The DomainProfile setting is used for both the down-level and the Windows Vista firewall. The StandardProfile setting is used in Windows Vista only if there is no configuration for the Public and Private profiles. If either has been configured, most StandardProfile settings are ignoredfirewall. However, any exceptions configured in the StandardProfile are copied to the PublicProfile and PrivateProfile areas. Likewise, the PublicProfile and PrivateProfile settings are used only by Windows Vista.

To work around this problem, you need to think carefully how you want the firewall configured on the different platforms. Then you need to implement two (at least) Group Policy objects (GPO); one per platform. If you want to keep the third-party firewall on Windows XP, but use the built-in firewall on Windows Vista, you would create a GPO for Windows XP, using the legacy settings, which turned off the firewall. Then you would create a GPO for Windows Vista, using the Windows Firewall with Advanced Security settings that turned on the firewall.

Next, you have two options for how to get the GPOs to apply only to the computers they are intended for. One option is to use separate Organizational Units-one for Windows XP-based computers and one for Windows Vista-based computers. You would have to manually move each computer into the proper OU. If a computer gets upgraded, it needs to be manually moved into a different OU.

A better option is to use WMI filtering. A WMI filter allows you to run a query against the Windows Management Instrumentation data store and filter group policy objects based on the results. Figure 11-24 shows a WMI filter that selects only computers running Windows Vista, based on the version of the operating system.

Image from book
Figure 11-24: You can use a WMI filter to apply different Group Policy settings based on the operating system version.

The query used in the WMI filter in Figure 11-24 returns a set of values if the version of the OS on the Group Policy client is 6.0.6000. The Group Policy engine on the client essentially puts application of the GPO within an if statement based on this query. If the query returns anything, then the GPO gets applied. If the query returns nothing, the GPO does not get applied. This is a very effective way to filter GPOs because if a system gets upgraded no change needs to be made to Active Directory to get the proper policies to apply.

Image from book
HOW TO SPECIFY VERSION IN WMI

The astute reader will notice that the WMI filter in Figure 11-24 looks for an exact match on the version. This is different than some documentation provided by Microsoft that looks for Version > 6.0. The disparity caused a great deal of debate during the review phase of the book. I dislike a greater-than filter for several reasons:

  • Version is a string attribute, not an integer. Performing greater-than comparisons on strings can have very interesting effects. For instance, 10.0 is less than 6.0.

  • The filter is used to specify which version of the OS these settings apply to. While you may want them to apply to Windows Vista, it is not clear at this point that you also want them to apply to any future versions of the OS. To avoid having to chase down scattered filters, and to ensure that you do not wreck a future version of the OS, you need to take an inclusive approach that specifies very restrictively what you want. This is the same approach you would take when writing input validation in software. You want to accept only that which you know is good.

When you write filters you should think about the result you wish to achieve and code the filter appropriately for that result.

Image from book

The only caveat to this is that you need the right OS version to filter on. For Windows Vista, as noted previously, it is 6.0.6000. For Windows XP it is 5.1.2600. If you wish to verify for yourself, or if you have some other version of Windows and want to learn what version it is, you can run this script:

     ' GetOSVer.vbs
     Option Explicit

     Dim objWMIService, objItem, colItems, strComputer
     strComputer = "."

     'Run the query
     Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
     Set colItems = objWMIService.ExecQuery ("Select * from
     Win32_OperatingSystem")

     For Each objItem in colItems
         Wscript.Echo "OS Version on this computer is: " & objItem.Version
     Next

     WScript.Quit

Copy this to a file called GetOSVer.vbs and double-click it. You can also find this script on the Web site accompanying the book, along with another script called GetOSData.vbs that returns all the values in the Win32_OperatingSystem collection-essentially everything you would ever want to know about your operating system.

RPC

We discussed, very briefly, that it might be a good idea to block RPC outbound in the public profile. One oft requested feature has been to control who can perform RPC lookups and connect to dynamic RPC ports inbound. RPC is an extremely common interprocess communications mechanism that uses a directory service of sorts. When a service that receives RPC traffic starts, it asks for one or more random ports. Once it gets that information, it registers its endpoints with the RPC Endpoint Mapper. A process on a remote computer that needs to communicate with the service would first ask the end-point mapper on the target computer where the particular service is. The end-point mapper would respond with the port number, and the remote process would then connect to the port.

From a security perspective, we might want to restrict who can connect to RPC ports on our computer. Restricting access to the end-point mapper is simple. It listens on TCP 135. Restricting access to the individual services is considerably more difficult. The new Windows Firewall gives us two features that can be helpful, however.

The first helpful feature is the pre-defined rules. Open the Windows Firewall with Advanced Security snap-in. Click Inbound Rules and click New Rule. Select Predefined: and you get the dialog box in Figure 11-25.

Image from book
Figure 11-25: Predefined rules exist for particular services.

The predefined rules are written for particular services only, but they make the job a lot easier if you want to restrict only those services. However, if you want to restrict all dynamic RPC traffic, they do not help much. In that case, select a custom rule instead, and click Next. Then select All programs (or only a particular program or service if you so desire) on the next screen, and click Next again. On the Protocol and Ports screen, shown in Figure 11-26, select the TCP protocol, and then click the Local port dropdown.

Image from book
Figure 11-26: Configure restrictions for dynamic RPC ports.

In the Protocols and Ports screen you get an option to restrict traffic to local dynamic RPC ports. This is exactly what we wanted but could not do in prior versions of the operating system. It is hard to decide which feature of Windows Firewall we like best, but this is definitely in the top-five or so of the list.


Summary

The Windows Firewall with Advanced Security is one of the most drastically modified features in Windows Vista compared to earlier versions of Windows. With almost surprising success, Microsoft has managed to combine significant power with an interface that you can actually learn and get comfortable with in an afternoon. It now has most of the features we have been asking for over the past several years, and the integration of IPsec and firewall is nothing short of a spectacular improvement in security manageability. We urge you to take a deep look at this firewall to determine how you can best use it.

There are certainly some features missing though. The most notable is the lack of per-interface profiles. All interfaces use the same profile-the most restrictive one. This means that if you use a VPN connection from a public network, even the VPN interface is configured with the public profile. You can work around that using the per-interface rules, but it would be much simpler with a per-interface profile. We are told this is coming in future versions of Windows. We would also greatly appreciate better integration between connection security and firewall rules.


Best Practices

  • Spend some time with the scenarios in this book and others that you can think of and go through how to implement them in the Windows Firewall.

  • Build separate GPOs for Windows Vista and Windows XP firewall configuration and use WMI to filter them.

  • Use outbound blocking sparingly. The most valuable filters are on by default already and most things you do beyond that do little for security and much to annoy your users.

  • Exempt your management traffic over VPN connections, as appropriate.

  • Turn immediately to Chapter 12 and learn how to use server and domain isolation to protect your Windows network.


Chapter 12: Server and Domain Isolation

Quite possibly the most powerful security measure in recent memory is something Microsoft calls Server and Domain Isolation (SDI). SDI has, in fact, become a marketing rallying cry for Microsoft, although it really started as a purely technical measure for restricting avenues of attack. Perhaps the first widely published use of the technique was Microsoft's winning entry in eWeek's OpenHack IV, in 2002, which predated the marketing term by several years. The principle of the defensive method used in OpenHack IV was simple: enumerate all necessary communications patterns in the network and allow those, and only those. This is effectively what Microsoft now calls Server Isolation. In this chapter, we describe the basics of SDI, and look at how the way you deploy it has changed in Windows Vista.

Server and Domain Isolation Overview

SDI is essentially about one thing: allowing only the traffic that needs to be allowed in your network. Fortunately, there is a way to put a security mechanism right between the network and the host layer. In essence, it is a network-layer security mechanism that is implemented on each host-to protect them from the network. There are several ways to think of SDI. One is in terms of deployment phases. Another is by looking at the different isolation mechanisms. The deployment phases are really just two:

  1. Analyze your network.

  2. Build IPsec rules to enforce the necessary and desired communications patterns.

The network analysis phase can be quite lengthy. The sad reality today is that the vast majority of organizations do not quite know what is on their network. This is almost to be expected given how fluid and complex the average network is. In fact, an organization that knows where 80 percent of the computers they have bought are on any given day is probably ahead of the curve. This is actually one of the major reasons for SDI itself: it forces you to get a better handle on your asset management and your network architecture. Even if you never get to the deployment phase, you have made your return on the investment several times over in the improved understanding of your network. Compared to the analysis phase, the deployment phase is probably relatively straightforward, if the analysis phase was properly done.

This chapter provides only an overview of SDI. Microsoft has published lengthy tomes on SDI on its Web sites. Most SDI documentation is linked from the SDI tech-center at http://www.microsoft.com/sdisolation. In particular, Microsoft's primer on the technology is quite useful for those looking to understand the basic concepts. In the remainder of the chapter, we explore the basic concepts of SDI and some of the rationale behind it, and highlight how Windows Vista has made implementing SDI easier and faster.

Domain Isolation

Domain Isolation is quite simple in concept, albeit not so simple in practice. The idea is to restrict communications in a network such that only machines that are members of the domain can speak to each other. The ability to stop non-domain members from accessing domain resources is a common request among many customers. They want to get better control over their information assets and prevent non-domain joined machines, which by definition are unmanaged machines, from accessing any network resources. The implementation of domain isolation involves deploying an IPsec filter that allows inbound connections from other machines in the domain but blocks connections from unmanaged systems.

This is where it starts getting more complicated. First, almost every environment has unmanaged machines that cannot be domain joined. For instance, a network printer might send logging data to a domain member, and there needs to be an exception in the IPsec filter to allow this. A further complication stems from the fact that you cannot secure all domain traffic with IPsec. The rationale is quite simple. The simplest method to implement the IPsec authentication is to use Kerberos. However, in order to use Kerberos, one must be domain joined. In order to become domain joined one must be able to connect to the domain controller (DC). In order to connect to the DC one must be able to negotiate an IPsec connection. In order to negotiate an IPsec connection one must be able to get a Kerberos ticket. In order to get a Kerberos ticket one must be domain joined. In order to … Well, you get the picture.

This circular dependency is why Microsoft has never supported client-to-DC IPsec. The DC, the very most valuable resource in the domain, must be unprotected by IPsec and accessible to all; otherwise you will never join another system to the domain. There are isolated deployments that have deployed client-to-DC IPsec anyway. In at least a few environments they made a conscious decision not to join any more systems to the domain. In others, the decision was to use certificate-based authentication for IPsec and then build an out-of-band deployment and servicing mechanism for the certificates. Starting with Windows Vista, certain limited client-to-DC IPsec scenarios are actually supported. More about that later.

Server Isolation

Server Isolation is a bit more complicated than Domain Isolation both in concept and in implementation. The astute reader would have noticed the fallacy in the logic behind pure domain isolation, however. A moderate-sized domain today consists of at least 5,000 computers. Do you really wish to allow connections from every one of those to every other computer? The total number of connections in that environment can range to 5,0002*numberOfProtocols each computer implements. How can you possibly hope to maintain the integrity of an environment that allows 500,000,000 + connections? Add a single computer and the number of connections increases exponentially. By the way, do most workstations really need to request services from each other? Do most clients need to connect directly to the back-end database servers? With only Domain Isolation, while you block unmanaged computers between domain members, all those connections are allowed. You have yourself a great big kumbaya network where everyone is fat, dumb, and happy, and trusts everyone else because they managed to convince someone to add them to the domain. When the next big worm comes, or when some counter-intelligence service breaks into your network, the attackers will have access to everything that the first domain-joined system they hack has access to; transitively.

This is where Server Isolation comes in. Server Isolation is about isolating servers (systems that provide services; in other words, not just your typical server) such that only those systems that have a legitimate need for their services can access them. The simplest example of this is a back-end database server. Users should not be allowed to run ad-hoc queries against many back-end databases. They should use well-defined front-end applications, which in turn access the back-end database on the user's behalf. As a slightly more complicated example, consider Remote Procedure Call (RPC) and Distributed Component Object Model (DCOM). The vast majority of machines that provide RPC and DCOM services to remote systems actually have no legitimate need to do so to the vast majority of systems in the network. This includes every Windows XP system. This problem gets even worse if you provide these services without authentication, as Windows XP and Windows XP Service Pack 1 (SP1) did by default. Using IPsec, you can block connections from systems that should never be allowed to request RPC, or DCOM, or database services, or any service you wish, from a particular system-on the system that provides the service. In other words, this provides actual enforcement, and does not just ask the potential attacker to behave nicely. At this point you may want to pause and con sider how much damage the SQL Slammer (http://www.en.wikipedia.org/wiki/SQL_slammer_worm) and DCOM Blaster (http://www.en.wikipedia.org/wiki/Blaster_worm) worms would have caused, had you deployed server isolation throughout the entire network.

Common fears about IPsec are that it slows down your network and blocks all your network monitoring tools. The latter is not true if you use ESP NULL; in other words, you select to encrypt packets but do not provide a key to do so. This is the default in Windows Vista and provides the authenticated traffic we desire. The former concern is only marginally true. IPsec, naturally, does impose a performance penalty, but it is quite small, on the order of 5–10 percent in prior versions of Windows. Windows Vista adds performance improvements to the TCP/IP stack, including IPsec. In addition, Windows Vista has added performance monitor counters for IPsec to enable users to monitor performance of IPsec.


Forget About the Perimeter

Several years ago our friend Steve Riley was running around the world delivering a presentation he called "Death of the DMZ." Steve was one of many insightful security professionals who were claiming that the perimeter was becoming increasingly meaningless as a defensive measure. The rationale behind this argument was based on a number of observations:

  • Perimeters are typically configured to allow a lot of traffic to pass through, needed or not.

  • A significant volume of traffic is being tunneled through other protocols at the application layer. This is the central tenet behind so-called "SSL VPNs," which encapsulate protocols ranging from Server Message Block (SMB) and RPC, to FTP and HTTP, in an HTTPS connection.

  • The size of organizational networks is so large that even if every single computer is patched 99.9 percent of the time, the likelihood that a network contains at least one unpatched machine at any given time is over 63 percent in a network of just 1,000 computers. Statistically, it is virtually impossible to keep an entire network up-to-date on patches before you even consider the fact that some computers inside the organization are operated by people hostile to the organization.

  • Computers transition between the external and the internal network constantly, bringing inside whatever they picked up on the outside.

  • It is almost certain that in any network of interesting size, there exists at least one router to the outside that is unmanaged. It may simply be a misconfigured system on a VPN connection, or it could be much worse.

  • The attacks today are attacking people, and sometimes the application layer. Firewalls and filtering routers do nothing to ward off attacks against people and they typically operate very low in the stack, at the network and transport layer. If a firewall understands application layer traffic, it is usually configured only to block traffic that is known to be bad, as opposed to allowing only that which is provably good.

All these factors contribute to the state we have today: where the perimeter is merely a marginally useful coarse filter. An organization that fails to realize that the perimeter does not truly protect it is not doing all it could, and should, to protect its information assets. Such a philosophy guarantees the success of a dedicated attack, and vastly increases the damage that will be caused by the next network worm. The standard of care today should include deeper protection inside the perimeter. It should include protection that blocks not just traffic from outside the network, but the vast majority of traffic patterns inside the network. Take our 5,000 computer network example: You could almost certainly take the 500,000,000 possible connections in that network and reduce them to 50,000 connections, a reduction of four orders of magnitude.

The old model that you have a perimeter that provides our primary protection is shortsighted and dangerous today. We should not rush to get rid of the perimeter. It is a useful defense-in-depth measure. However, we must provide additional restrictions inside the network. David LeBlanc, of Writing Secure Code fame, once said that "the vast majority of organizational networks today are semi-hostile at best." He was absolutely right. There are malicious hosts and malicious users inside every single network. Add to that the egg-shell design, based on the false conception that there is a concrete, as opposed to abstract, perimeter. Take all these factors into account and it is only a matter of time before the whole house of cards falls.


Network Threat Modeling

To implement server isolation you must understand how your network really works and what traffic it needs to support. This problem sounds complicated, but can be tackled using network threat modeling. Network threat modeling is basically a technique to turn a network diagram into a data flow diagram for a network.

To start network threat modeling, you need a network diagram showing all the computers and other devices in your network. Once you have a diagram, try to abstract individual computers into host classes as much as possible. For instance, most of the clients running Vista probably are relatively interchangeable. You can abstract classes of computers that perform the same tasks into a single entity on the diagram.

Once you have a picture of the computers in your network, you annotate the picture with the communication patterns that are needed within your network. This is the traffic that is required to provide the functionality you need in your network. It represents the threats that you cannot entirely mitigate. (All traffic that is not needed represents threats that you can mitigate.) Ensure that you cover all traffic parameters, including the following:

  • Is the traffic defined by source address or host class?

  • Is the traffic defined by destination address or host class?

  • What is the source port?

  • What is the destination port?

  • Directionality-is the traffic unidirectional or bidirectional?

  • Can this type of traffic require IPsec? (Some traffic, such as a domain controller to domain member traffic may not be able to require it.)

  • Is the data being transferred sensitive?

When you are done, you can build a table that documents all the traffic. The beginnings of such a table is shown as Table 12-1.

Table 12-1: List All Communications in a Table Open table as spreadsheet
ORIGIN HOST(CLASS) | DESTINATION HOST(CLASS) | SOURCE PORT | DESTINATION PORT | BI-DIRECTIONAL | AUTHENTICATION REQUIRED | ENCRYPTION REQUIRED
Domain members | File servers | Ephemeral | 445 | Yes | Yes | No

The table, for all practical purposes, defines the IPsec rules you need to implement. If you do well in this stage, the rest of the implementation is considerably easier. If you are a command-line junkie, you can build the table in Excel and use a macro to build the rules. If you are not that industrious, then just use the table as a check-off list when you build the rules.

This has been a very quick introduction to modeling your network. A more thorough discussion of this topic, with more detailed examples, is beyond the scope of this book, but this information will get you started. A useful modeling technique is detailed in Protect Your Windows Network.


Changes in Windows Vista Affecting SDI

With all the changes in the firewall and IPsec implementation in Windows Vista, it stands to reason that the way you implement SDI has also changed a bit.

AuthIP

We discussed in Chapter 11 how IPsec now supports IPsec user authentication (called AuthIP). AuthIP enables a number of new scenarios that were simply not possible with only computer-based authentication. One of them is the oft-requested client-to-DC IPsec we discussed earlier.

Client-to-DC IPsec

Recall that the primary issue with client-to-DC IPsec was that systems that are not joined to the domain cannot negotiate IPsec with the DC. This now works in pure Windows Longhorn Server domains with Windows Vista clients. When an administrator attempts to join a system to the domain, the administrator is prompted for a user account with rights to access the DC and join the system to the domain. The IPsec communication is negotiated using the NTLMv2 protocol and the user credentials. This resolves the boot-strapping issue that was the primary blocker of IPsec between clients and DCs.

Authentication with Multiple Credentials

One problem with the typical IPsec-based server isolation scenario is that the connection is not restricted to legitimate users. If an attacker manages to take over a trusted computer the attacker can do anything that any user on that computer can do. Using AuthIP, you can restrict a connection not only to a particular computer, but also to a particular user. We showed this in Figure 11-12 in the previous chapter, which is repeated here as Figure 12-1.

Image from book
Figure 12-1: You can restrict connections to only particular users.

Keep in mind that Figure 12-1 shows an inbound rule setting out requirements only. The directional rules do not, as we pointed out in Chapter 11, actually configure the IPsec rules. To do that you have to provide a connection rule that actually secures the traffic.

Improved Negotiation Flow

With IPsec there is typically no fall-back of authentication methods. However, in Windows Vista, a computer can try several protocols during an IPsec negotiation. This permits you to specify which protocols you prefer, as well as which you would allow if the ones you prefer fail. You can specify the protocol preference order both for user and computer authentication, as shown in Figure 12-2.

Image from book
Figure 12-2: You can now specify which authentication protocols are preferred.

Falling back to less preferred protocols is a great feature for computers that may not have been completely configured yet. The perfect example is a computer that is not yet domain joined. By using NTLMv2, which, by the way, is a new protocol for IPsec purposes that is not supported in prior versions of Windows, a non-domain joined computer can negotiate IPsec to a domain controller.

Vastly Improved Configuration User Interface

Perhaps the biggest change of all with respect to SDI is the vastly improved configuration interface. Figure 12-3 shows a portion of the many "wizards" used to build an IPsec rule in previous versions of Windows.

Image from book
Figure 12-3: Configuring IPsec rules in prior versions of Windows was anything but easy.

The user interface has been improved in more ways than just usability in Windows Vista. It has also been extended to include pre-canned "wizards" for SDI rules. When you start building a connection rule-a rule that specifies how a permitted connection must be secured-in Windows Vista, you start out with the screen shown in Figure 12-4.

Image from book
Figure 12-4: The initial screen on the connection security rule wizard asks you to select a rule type.

Domain Isolation Rules

Isolation rules are the rules that restrict connections based on various criteria, such as domain membership. Building a rule to allow inbound connections only from domain members is actually quite simple with this wizard. Make sure Isolation is selected, as shown in Figure 12-4, and click Next to get the window in Figure 12-5.

Image from book
Figure 12-5: First you define which connections you require authentication on.

In Figure 12-5, you get to define whether you want to require or request authentication, and on which types of connections. If you are building a domain isolation rule for clients, you probably want to require authentication on inbound connections, as clients should not be servers-but only request it on outbound connections as not all servers may support IPsec. With prior versions of Windows, it was paramount to also have a large number of exceptions that did not require authentication. The reason was that the fall-back to clear when a client requested authentication and the server did not support it was longer than the reset interval on most connections. The result was that even if a computer was set up to request but not require authentication, all outbound connections configured this way failed. This was fixed in Windows Vista by changing the fall-back to clear time-out value when a computer requests authentication. A computer will now fall back to clear text much faster, making it possible to request encryption in scenarios where the request may be ignored. Previously such requests would almost invariable result in failed connections. This change was also back-ported to down-level platforms. See Microsoft Knowledge Base article 914841 for more details.

The next step is to decide which type of authentication to use. Figure 12-6 shows the screen for this. The default selection, somewhat surprisingly, is "Default."

Image from book
Figure 12-6: You can customize authentication protocols.

On this screen you may notice that the option for pre-shared keys has been removed. Pre-shared key IPsec authentication is still supported, under the Advanced option, but is highly discouraged. Not only are pre-shared keys an absolutely nightmare to manage, but they are also stored in clear-text in the registry, making them notoriously insecure. The default option uses whichever authentication options are configured via Group Policy for the firewall itself. The defaults can be configured in the firewall properties, as shown in Figure 12-7.

Image from book
Figure 12-7: Set the default authentication options in the firewall properties.

Paradoxically, the dialog box in Figure 12-7 that you use to configure the default authentication options also has a default option. In other words, the default is to use default, which defaults to default. Fortunately, the default is "Computer (using Kerberos v5)," which is probably what you want anyway, if you haven't become so confused by now you have given up entirely. (By default, it is actually not as confusing as the defaults may seem.) Leave it alone and you get computer authentication using Kerberos v5.

The only thing left after Figure 12-7 is to configure which profiles you want this rule used in. You may not want it in all profiles. If it is a domain isolation rule, for instance, and it uses Kerberos as the authentication protocol, it would be quite meaningless to allow it to be used when the computer is in the public profile.

It is also important that you create the appropriate exceptions using directional rules to allow the IPsec secured traffic to make it through. Remember from Chapter 11 that when sorting out precedence for firewall rules the most restrictive rule wins. In other words, if you have a connection security rule that allows some traffic, but there is no inbound rule that permits it, the traffic is blocked because the inbound firewall will block it before the IPsec filter even comes into play. However, if you have a directional rule that allows the traffic if it is secure, the connection security rule will take effect and allow traffic that meets its requirements.

For this reason, we recommend that you create an inbound rule in the firewall that allows all traffic from domain members if it is secure. This creates a blanket IPsec bypass that permits all traffic that matches the conditions of one or more connection security rules. If no connection security rules permit the connection, it will be blocked at the IPsec layer.

Server Isolation Rules

Server Isolation rules are also much simpler to build in Windows Vista than in earlier versions of Windows. First, go back to the screen shown in Figure 12-4 and select a server-to-server rule. Next, select which computers are in the two endpoints. This is shown in Figure 12-8.

Image from book
Figure 12-8: Select end-points for a server-to-server rule by IP address.

As you can see in Figure 12-8, you can configure server isolation rules for ranges of IP addresses. However, you cannot configure them for hostnames. In other words, server-to-server isolation rules can be difficult to build for clients where you typically use DHCP. However, if you simply want to permit inbound connections from one or a few systems, such as a management station, the problem can be solved by ensuring that the management station(s) have predefined IP addresses. In that case, you would simply specify one of the endpoints as "Any IP address." As far as IPsec is concerned, there is no concept of "my IP address." IPsec does not consider the direction traffic was sent in the same way a firewall does. Therefore, either endpoint 1 or endpoint 2 can be "Any IP address." It makes no difference either way.

Once you have selected the endpoints, the rest of the rule configuration proceeds exactly like a domain isolation rule, with selecting the connection requirements authentication, which profiles the rule applies in, and so forth. Oddly enough, the Domain member authentication options do not appear in the authentication dialog box for server-to-server rules. You have to select Advanced and then Customize … to select Computer (Kerberos v5) to use Kerberos for authentication. Stranger still, the Preshared key option is shown in this dialog box. There may be some solid reasoning behind this dialog box design, but it could also be that Microsoft did not complete the UI design for connection security rules.


Summary

This has been a short introduction to how SDI can help you secure your network. We have covered how the implementation of SDI has changed in Windows Vista. SDI, as a security technology, is remarkably static. The concept itself is actually one of those timeless pieces of solid engineering that is invariant with platforms. As new platforms come along, the actual ports that need to be opened change, and the mechanism to do it with varies a bit. However, the core goal of allowing only the traffic you absolutely need in your network does not change. It is one of the most valuable, and most underused, security technologies available today. Do not overlook the tremendous potential it has for helping you protect your network.


Best Practices

  • Investigate how SDI can help you protect your network.

  • Start a project to analyze traffic patterns in your network today.

  • Configure domain controllers to request computer authentication but allow fallback to user authentication to support non-domain-joined computers.

  • Require all new service owners to threat-model their services and document the interfaces they expose, to whom, and why.

  • Support SDI in your security policy to codify the practice of blocking all traffic that is not necessary.


Chapter 13: Wireless Security

Wi-Fi networks have become a common connectivity tool in most corporate and many home environments. Unfortunately, a large percentage of users have installed Wi-Fi networking without any security defenses or with weak defenses. This chapter covers Wi-Fi terminology, threats to 802.11 wireless networks, and improvements in wireless for Vista. It also discusses the general and detailed steps needed to implement strong security on Windows wireless networks.

Note

Chapter 13 focuses on Wi-Fi 802.11 network technologies. Other wireless technologies that are normally used for other purposes-such as Bluetooth, cellular, and infrared-will not be covered.

Wi-Fi Terminology and Technologies

There are so many wireless networking terms and standards that it makes the normally acronym-obsessive computer world seem quaint. Many users get lost in the dizzying array of initials and definitions so that they aren't sure what any of the wireless protocols and acronyms mean.

Wi-Fi Standards

Wi-Fi networking refers to globally accepted, wireless communication protocols based on the 802.11 standards governing Wireless LANs (WLANs). Wi-Fi is a trademark of the Wi-Fi Alliance (http://www.wifialliance.com) and does not stand for Wireless Fidelity, as some people believe. Wi-Fi is most often used in local area networks but can be used for wide area networks, music players (Microsoft's Zune uses Wi-Fi for music trading), cell phones, gaming consoles, and automobiles.

A Wi-Fi network is composed of one or more access points and nodes (see Figure 13-1). An access point (AP) normally connects one or more wireless nodes (or clients) together using 802.1l technologies. Wireless APs normally broadcast beacon packets advertising their Service Set Identifier (SSID) (i.e., network name). Beacon packets advertising the SSID are normally transmitted so that listening nodes can connect to the AP, although this feature can be turned off. Wireless APs often connect a wireless network to a wired network (although that doesn't have to be the case), and it can function in bridged, Network Address Translation (NAT), or routing mode.

Image from book
Figure 13-1: Typical Wi-Fi setup

Infrastructure versus Ad-Hoc Mode

There are two access point modes: Infrastructure and Ad-Hoc. Infrastructure mode is when an AP is a terminating network device designed to support multiple wireless nodes at once (much like a wired hub). It often interfaces the wireless network to the wired network. Most APs are in Infrastructure mode by default.

Ad-hoc mode APs use peer-to-peer connections. Normally, every computer that has a wireless network card can act as an Ad-hoc mode AP. Prior to Vista, Windows clients would often connect to Ad-hoc mode APs if Infrastructure mode APs could not be found. This, despite the fact that most wireless users only intended to connect to preconfigured Infrastructure mode APs (called preferred networks). Malicious hackers have used rogue Ad-hoc nodes to attempt to compromise wireless nodes. Windows XP Pro (SP2 and later) and later Windows OSs will warn the user if the user attempts to connect to an Adhoc mode or unsecured AP.

If two or more APs with the same SSID are within range of the node, the node's software will normally choose the stronger signal (although it depends on the node's wireless network drivers). Access points normally have 11 or more channels that can be used, although many places outside the United States have more (Europe has 13, Japan has 14). Most APs can only use one channel at a time. However, many vendors, like Cisco, offer multi-channel APs for load balancing.

Each channel is a separate broadcast spectrum, although because of a wireless phenomena called harmonics, if multiple APs are in range of each other, channels that can be divided or multiplied by two to equal another channel should be avoided. Thus, you would not want one AP to use five and another to use ten. Traditionally, most administrators installing multiple wireless APs in the United States use channels 1, 6, and 11 to prevent unintended interference.

Wi-Fi uses Collision Avoidance (CA) to try and avoid network packet transmissions from client nodes. The practical effect is that every node on the same AP and channel can see all the traffic headed to and from every other node, just like legacy Ethernet hubs. Without protection, any node on the same channel can see everything the other node is transmitting and receiving.

Wi-Fi Standards

There are four main 802.11 Wi-Fi standards:

  • 802.11a

  • 802.11b

  • 802.11g

  • 802.11n

Regardless of its lettering, 802.11b was the first widespread Wi-Fi standard in use when wireless networking took off. It uses the 2.4 GHz spectrum, can transmit up to 11 Mbits/second (1 Mbits/sec is the minimum for all Wi-Fi connections) reliably up to 100 meters (physical infrastructure not withstanding). Inside maximum range is closer to 35 meters.

802.11a operates at the 5 GHz spectrum and can transmit data up to 54 Mbits/second up to 75 meters outdoors and 25 meters indoors.

802.11g operates at the same 2.4 GHz spectrum as 802.11b, but can send data up to 54 Mbits (like 802.11a), and for the same distances as 802.11a.

Because 802.11b and 802.11g share the same 2.4 GHz spectrum, many APs and nodes support them jointly (called 802.11b/g). Of course, maximum transmission distances must take into account physical surroundings and interference from other sources. They can be extended using specifically developed "extender" devices.

A new Wi-Fi standard, called 802.11n, is emerging to final approval in the 2007/2008 timeframe. 802.11n supports data rates up to 540 Mbits/second over 2.4 or the 5.0 GHz channels for indoor distances not to exceed 50 meters. 802.11n gets its incredible speed boost by using multiple transmitting and receiving antennas on each AP, known as Multimedia In Multimedia Out (MIMO) technology. Several vendors already support 802.11n and MIMO.

802.11n network equipment is expected to support one or more of the previous standards for backward compatibility, although if even a single node is running at a slower speed, it makes the AP and all attached nodes run at the same reduced speed. Additionally, the 2.4 GHz spectrum is licensed to HAM radio operators and is used by wireless telephones, baby monitors, and so on. Those devices may interfere with Wi-Fi networks operating in the same bands. Table 13-1 summarizes the various Wi-Fi transmission standards:

Table 13-1: Wi-Fi Technology Comparison Open table as spreadsheet
WI-FI STANDARD | CHANNEL BAND | MAX. SPEED | MAX. DISTANCE
802.11a | 5.0 GHz | 54 Mbits/second | 75 meters
802.11b | 2.4 GHz | 11 Mbits/second | 100 meters
802.11g | 2.4 GHz | 54 Mbits/second | 75 meters
802.11n | 2.4 or 5.0 GHz | 540 Mbits/second | 50 meters
Note

There are many other wireless standards, including 802.11p, for automobile and transportation Wi-Fi transmissions, and 802.16, WiMAX, for wireless metropolitan area networks. But 802.11a/b/g are by far the most popular computer wireless standards at the moment.

Wi-Fi Security Standards

Wi-Fi security standards have just as many acronyms. Each security standard refers to authentication (computer or user), data integrity, encryption, or all three. The following is a description of these standards. A further examination of their strengths and weakness and when to use each of them is covered at the end of this chapter.

Wired Equivalent Privacy

Wired Equivalent Privacy (WEP) was the first widespread encryption protocol for Wi-Fi networks. Developed in 1999 along with the initial 802.11b Wi-Fi explosion, WEP provides weak encryption and even weaker data integrity. While WEP was originally thought to provide good encryption, it was quickly found to have several flaws. Its encryption routine relied upon a weak RC4 encryption initialization vector (IV) and a short key length.

Several wireless cracking tools, such as Airsnort (http://www.airsnort.shmoo.com) or Chopchop (http://www.netstumbler.org/showthread.php?t=12489), make cracking WEP-encrypted packets take only seconds (after collecting the needed hundred thousand or so WEP packets). WEP's data integrity relies upon a very weak cyclical redundancy check (CRC) that in the crypto world gets no respect.

WEP comes in two default strengths, 64-bit (actually, it is 40-bit crypto strength with a 24-bit IV) and 128-bit, although a 256-bit version was later added in an attempt to extend WEP's useful life. WEP requires that the administrator input an identical, shared character string into the AP and all participating nodes. Figure 13-2 shows a 128-bit WEP key being inputted into Vista. Each inputted hexadecimal character added 4 bits of strength, which when added to the 24-bit IV made up the entire WEP encryption strength (weak as it was). Thus, 64-bit WEP required the administrator to type in 10 hexadecimal characters (10 characters × 4 bits − 40 bits + 24 bit IV = 64), 128-bit required 26 hexadecimal characters, and 256-bit WEP required 58 inputted hexadecimal characters.

Image from book
Figure 13-2: Manually inputting a WEP key

Manually inputting the WEP keys can be a painstaking process. Most WEP vendors simply disabled WEP by default, so users could plug in their Wi-Fi equipment and get working. To this day, most wireless surveys reveal 40 to 50 percent of all Wi-Fi networks as unprotected.

Unfortunately, even if users enabled WEP, it is only to block the casual intruder. Today, WEP should only be used if that is all the legacy wireless components support. It's better than broadcasting in plain-text. Wi-Fi WEP users should consider upgrading their WEP-protected wireless networks to a newer security protocol or use an alternative end-to-end client protection protocol, such as IPsec or a proprietary VPN client.

Wi-Fi Protected Access/802.11i

Wi-Fi Protected Access (WPA) was an intermediate standard intended to correct WEP's deficiencies. WPA has now been replaced by a more mature version of the WPA standard, known as WPA2 or 802.11i. As with WEP before it, WPA (version 1) should not be used if WPA2/802.11i can be used. However, it should be considered over plain-text transmission and WEP.

WPA/WPA2 uses stronger cryptography. Data is encrypted using an improved RC4 cipher, with a minimum of a 128-bit key and a 48-bit IV. A new protocol called Temporal Key Integrity Protocol (TKIP) takes any original key used in the beginning of WPA/WPA2 transmissions and constantly updates it. The key used to encrypt data changes dynamically, and unpredictably, making WPA/WPA2 a much stronger Wi-Fi encryption protocol. WPA2 uses the Advanced Encryption Standard (AES) cipher for data confidentiality. Additionally, a new Message Integrity Code (MIC) is used as an authenticated hash for data integrity. It prevents undetected data manipulation and traffic replay.

WPA2 has two modes: Personal and Enterprise.

WPA Personal Mode

WPA Personal uses a Pre-Shared Key (PSK) similar to the shared, character string that WEP required (see Figure 13-3). The PSK can be from 8 to 63 ASCII characters long. The only difference is that if the user chooses a strong PSK (14 or longer random characters), the WPA2 standard is strong enough to withstand most cryptographic attacks. Unfortunately, sharing a PSK between the AP and the various nodes makes the PSK susceptible to unauthorized interception. The strength of your PSK might not be how long and random it is, but how securely you store the document you write the PSK down on.

Image from book
Figure 13-3: Manually inputting a WPA2 key

Writing down PSKs is never a good security practice. Accordingly, the Wi-Fi Alliance approved a newer, easier method called Wi-Fi Protected Setup (WPS). It allows the initial PSK to be generated by the WPA2 participating equipment. The user can either press a physical button on the AP, and all wireless nodes within reach of the AP can join the WPA2 network (not that secure, but very easy), or type in a previously determined 4- or 8-character PIN as the initial negotiator.

Additional methods (not yet formally approved as this book goes to press) will include tokens, smart cards, and USB flash devices. Regardless of the "boot-strap" method, it allows WPS-enabled equipment to pass a PSK between the AP and listening node. Many vendors already support WPS or a similar method. You can get more information on WPS at http://www.wi-fi.org/news/010807-wifi-protected-setup/en.

Note

Earlier versions of Wi-Fi Protected Setup, before the standard and name was resolved, are known by many different names. For example, Dlink called it WPA2-Auto Wireless Security (Enhanced).
WPA2 Enterprise Mode

WPA2 Enterprise mode relies on an 802.1X authentication server (notice it is 802.1X, not 802.11x) and 802.1X clients. 802.1X is also known as a network access control protocol. It can be used for wired and wireless authentication, although its initial use has focused on WPA2 wireless client connections. Wired 802.1X connections are managed by a new Vista service called Wired AutoConfig.

Windows 2000 (fully service packed) and later supports WPA2 and 802.1X client authentication. Microsoft's Internet Authentication Service (IAS), or Longhorn's new Network Policy Server (replaces IAS), can be used as 802.1X servers for either wired or wireless networks.

Note

802.1X authentication is server and client node authentication only. If used alone, without WPA2/802.11i, there still could be data encryption and user authentication issues. If WPA2/802.11i is used, it includes both authentication and encryption.

The communication protocol between the client and the server is known as Extensible Authentication Protocol (EAP). And as the name correctly implies, it is extensible and comes in many versions, including:

  • EAP-TLS (available in Windows XP and Windows Server 2003)

  • EAP-TTLS/MSCHAPv2

  • PEAP/MSCHAPv2 (default in Vista and Longhorn server)

EAP-TLS supports digital certificates and smart cards. EAP-TTLS/MSCHAPv2 supports user authentication, and PEAP-TLS supports a stronger, even more protected EAP protocol. PEAP (Protected EAP) establishes a secure channel before initiating the standard EAP protocol. Expect the future to bring many more EAP-related protocols and acronyms.

Note

Previous versions of Windows, prior to Vista, supported EAP-MD5. It is being deprecated, although it can still be enabled with a little work (http://www.support.microsoft.com/kb/922574).

Enabling WPA2 Enterprise mode takes planning. In order for a wireless network to support a particular standard (for example, WPA2, or otherwise), the following components must support the desired protocol:

  • Access point

  • Wireless network interface card

  • Wireless network interface card drivers

  • Supporting operating system

It is not uncommon for one or more older components not to support the latest standards. Some components can be upgraded using software or firmware upgrades. Others have to be replaced completely. Check with your vendor on supported standards and updates.

WPA2 Enterprise mode requires the most setup and preparation of all the discussed wireless standards. The following tasks summarize enabling WPA2 Enterprise mode:

  1. Decide on whether computer or user authentication or both, will be used to authenticate to the wireless network infrastructure.

  2. Configure your Public Key Infrastructure (PKI) services, as can be provided by Microsoft Certificate Services, to create and distribute the appropriate digital certificates.

  3. Install digital certificates on computer or smart cards.

  4. Configure and enable a participating RADIUS or 802.1X authentication service. The authentication server must normally have its own identity digital certificate in order to authenticate to the connecting client and to securely transmit security information back and forth.

  5. Configure wireless access point to accept WPA2 Enterprise authentication, pointing the access point to a valid RADIUS or 802.1X authentication server.

  6. Configure wireless computers to use WPA2 Enterprise authentication, with the appropriate settings selected.

Note

This book will focus on the Vista, client configuration tasks. To configure Microsoft Certificate Services for WPA2/802.1X security, see http://www.microsoft.com/technet/security/prodtech/windowsserver2003/pkiwire/swlan.mspx?mfr=true.

First, you must decide whether you want computers or users to authenticate. Computers authenticate using computer (also called machine) digital certificates. They must be requested and installed on the client computers that wish to communicate. Alternately, you can require users to authenticate instead of the computer. Users can authenticate to the authentication service using a digital certificate stored on a Smart card (EAP-TLS) or using a logon name and password (EAP-MSCHAPv2). Once the choice is made, a PKI service should be appropriately configured and the certificates generated and distributed.

Microsoft's Internet Authentication Service (IAS) or Network Policy Server (NPS) can be used for client authentication. The participating wireless access point must be configured for WPA2 authentication and pointed to the appropriate authentication services (see Figure 13-4 for an example access point configuration screen).

Image from book
Figure 13-4: Example WPA2 setup options at the access point

Next, the client has to be configured with a wireless WPA2 Enterprise connection. Figure 13-5 shows a Vista wireless connection being configured for WPA2-Enterprise. The Encryption type can be TKIP or stronger AES.

Image from book
Figure 13-5: Configuring a WPA2-Enterprise connection

The network authentication method can be Protected EAP, smart card, or digital certificate. When Protected EAP is chosen, the user authentication can be confirmed using a user password (EAP-MSCHAPv2), as shown in Figure 13-6, or it can require a smart card or digital certificate. As Figure 13-7 shows, when EAP-MSCHAPv2 is chosen, you can configure Windows to automatically supply the user's logon name, password, and logon domain name as the default user authentication credentials.

Image from book
Figure 13-6: Using WPA2 with EAP-MSCHAPv2
Image from book
Figure 13-7: Instruction EAP-MSCHAPv2 to use user's default logon name and password

"Validate server certificate" should also be chosen to make sure the remote server authenticates to the client, preventing man-in-the-middle attacks.

If the option Enable Quarantine checks is selected, the Vista client will participate in Network Access Protection (NAP), which can be delivered by Windows Server 2003's Network Access Quarantine Control/RRAS/IAS services or Longhorn's new Network Policy Server. Network Access Protection enables an administrator to verify that connecting clients have met various minimum standards (for example, up-to-date antivirus software installed, fully patched OS, and so on) before allowing access to any network resources beyond the limited quarantine area. See http://www.microsoft.com/technet/network/nap/default.mspx for more details.

If smart cards and certificates are chosen for WPA/WPA2 network authentication, you can choose between a smart card certificate or a computer digital certificate (see Figure 13-8). WPA2 and EAP are very versatile protocols.

Image from book
Figure 13-8: Configuring WPA2 to require computer certificate authentication

In closing, all administrators should strive to be using WPA2/802.11i Wi-Fi security. It contains strong, examined, cryptographic encryption and authentication. Windows Vista and Windows Server supports 802.11 security. As you'll soon see there's a reason why you need wireless security.


Wireless Threats

By default, wireless network traffic is unbounded, unauthenticated, and unencrypted. Without any additional protection, wireless network traffic can be intercepted anywhere the wireless waves can be detected, recorded, and manipulated.

In the author's opinion, most active Wi-Fi networks have been detected by an unauthorized outsider, and many of them have been compromised. Too many wireless network operators don't think they will ever be attacked. There are even dozens of online Web sites dedicated to listing active Wi-Fi spots. Some budding computer security consultants, hungry for work and with questionable ethics, search for and break into unsecured Wi-Fi networks as a way of gaining new business. Rogue war drivers even have their own map symbols (http://www.en.wikipedia.org/wiki/Warchalking) so that roaming Wi-Fi searchers can find active Wi-Fi locations. The main wireless vulnerabilities are:

  • Eavesdropping

  • Unauthorized access

  • Bypassing of traditional defenses

  • Malware injection

  • Denial of service attacks

Eavesdropping

Wireless networks are most at risk from unauthorized eavesdropping. Unlike wired networks, which require the intruder to be physically joined to the network, unprotected wireless networks can be intercepted from distances moderately far away from the source.

Sniffing wireless networks only requires that the listener have a wireless network card and the appropriate software. Specialized wireless locating programs, such as NetStumbler (see Figure 13-9) can be used to locate, identify, and categorize wireless networks. Other programs such as Airsnort or Wire-shark (http://www.wireshark.org) can easily sniff the traffic and break down the various frame types and functionality. Any plain-text information and passwords can easily be seen in the network packet traces.

Image from book
Figure 13-9: Network stumbler in action

Most readers might think that the typical 802.11 network can only be listened into from a few hundred feet away (http://www.compnetworking.about.com/cs/wirelessproducts/f/wifirange.htm), but 802.11 traffic has been successfully sent over 125 miles (http://www.news.com.com/New+wireless+record+claimed/2100-7351_3-5835374.html) between the source and destination. While these wireless records don't normally occur with traditional 802.11 equipment, an attacker with a small investment in equipment can listen into wireless networks up to a mile away.

Using standard equipment, wireless hackers can drive (war driving) in a neighborhood or business area and find zones to hundreds of vulnerable networks. Wireless hacking is so widespread and well known that a parked driver working intently on their laptop is likely to be suspected as a wireless hacker by the regular police. It doesn't take a special degree to hack or to get caught.

Most wireless network access points function in "hub mode" meaning that any packet information sent to and from the access point is readable by any other listener. Most wireless users don't know this. An attacker can glean passwords, password hashes, application fingerprinting, host IP addresses, machine names, and more.

Unauthorized Access

It is also very common for intruders to gain unauthorized access. They may want to access and attack existing wired servers or simply use the company's wireless network as an entry point for free Internet access. Nearly every reader probably has a story of a friend (or themselves) using a neighbor's wireless Internet access without their authorization. Many courts have ruled that unauthorized use of a person's wireless network is illegal, but at times the access may even be unintentional. Unfortunately, many of our computers will connect to whatever unsecured wireless network they can find first, and the average user doesn't know enough about wireless networks to be able to differentiate between the correct and incorrect networks.

Intruders using unauthorized wireless access points have used those networks to attack other computers, to download child pornography, and criminal activities. When the authorities trace back the malicious behavior, the attack trail ends at the wireless network. It is usually difficult to impossible, without appropriate logging being enabled first, to track down the intruder.

Bypassing of Traditional Defenses

In the corporate environment, wireless networks are often less secure, both inbound and outbound, than their wired counterparts. If wireless networks do not have the same protection, they can be used to bypass the company's normal computer security defenses. Users denied access to particular functionality could turn to the wireless network to bypass firewalls, proxy filters, and other implemented mechanisms. A wireless user's computer could become compromised and offer an exploit avenue to the malware or remote hacker.

Malware Injection

Malware and hacking tools can also be injected into wireless network streams. For example, many worms work by using broadcast protocols or by randomly generating new target IP addresses. A wireless intruder could sniff a wireless network, learn the involved IP addresses, and then generate a network packet containing the MS-Blaster (http://www.symantec.com/security_response/writeup.jsp?docid=2003-081113-0229-99) worm that targets an unprotected computer. Once the MS-Blaster worm has infected one host, the worm itself will continue searching for new victims. MS-Blaster is one example, but literally thousands of malware infections and tools can be injected into a wireless network stream.

Even worse, prior to Vista, Windows had an insecure behavior that made wireless injection easy. If your legacy computer normally connects to a preferred wireless network, but then is unable to connect (for example, corporate laptop wireless user now working in an airport) to that wireless network, it will then create a random wireless network name (SSID) and place itself in infrastructure mode, advertise its presence using beacon packets, and readily accept incoming connections from other unauthenticated nodes. Yes, that's right. If your legacy Windows computer can't find its preferred wireless network, it will create its own insecure Wi-Fi network, advertise its presence, and allow other computers to attach to it.

While the new connecting, unauthorized user, doesn't have immediate access to your computer's hard drive or data contents, it is as if they are on the same (wired) network. They can try to break into your computer using all the normal remote Windows hacking tricks, sniff data, port scan your computer, and inject malware as discussed previously. Luckily this behavior is fixed in Windows XP Pro's Wireless Client Update for Windows XP with Service Pack 2 and Windows Vista. XP Pro, with the added client, will use a 128-bit protection key and enable the strongest security protocol available on the wireless network adapter. Vista doesn't allow inbound connections, period!

Denial of Service Attacks

Wireless networks are traditionally unstable by nature. They ebb and flow, losing and gaining signal strength as conditions and external influences dictate. Unprotected wireless networks are unauthenticated by default, and easy to jam or interrupt. First, there are a myriad of ways to interrupt Layers 1 and 2 on a wireless network. Anyone can send a wireless jamming signal that could take down your wireless network until the source is identified (not easy to do) and removed.

Second, several tools, such as Void_11 and WAN_jack, actually inject rogue traffic to intentionally kick legitimate nodes off of Wi-Fi networks. This can be done simply to deny legitimate service, although it is often done to force significantly more re-connection traffic, which results in more wireless traffic, which leads to faster encryption compromises. If you have ever been involved in a wireless denial of service compromise, they can be frustrating to eliminate. Often, the attacker will stop the DoS attack tool just when you are getting close to identifying the malicious node's location, stopping the investigation in its tracks without any possible recourse or continuation until the next attack.

All of these attack types are possible because wireless networks are unauthenticated and unencrypted by default.


New Wireless Improvements in Vista

There have been dozens of wireless improvements in Windows Vista over previous Windows versions. Here's a brief cap of the most significant ones.

  • Wireless configuration is integrated into the new Network and Sharing Center versus having to configure under the wireless network adapter.

  • Wireless networks can be configured per user or for all users on the machine. Per-user wireless profiles are disconnected when the user logs off.

  • Separate wireless profiles can be configured for the network standard profile and the domain profile, so different security can be configured when the machine is attached to its home Active Directory domain and when away.

  • Wireless networks that don't broadcast their SSID can not be added to the list of Preferred Networks. The SSID value of non-broadcasted networks shows up as Unnamed Network. In previous Windows versions, non-broadcasted networks could be used, but could not be added to the Preferred Network list. This became problematic if the involved computer needed to connect to a non-broadcasted wireless network when it was also in the range of a broadcasted wireless network. The computer would always connect to the broadcasted wireless network first, and the computer would then have to be disconnected and then re-connected to the non-broadcast network.

  • Users will be prompted to confirm whenever connecting to an unsecured network. This continues a behavior added to Windows XP Pro with SP2.

  • The Network Connection wizard will list all the security methods supported by the wireless network adapter (for example, WPA2, WEP).

  • Native WPA2 support was added. In Windows XP SP2, WPA2 support was added with an additional WPA2 client program.

  • WPA2 authentication options can be configured using group policy.

  • Using group policy, you can define a whitelist or blacklist of allowed or denied SSID names. Blacklisting could be useful when several unauthorized broadcasting wireless networks are all in reach of the computer or to prevent laptops from connecting to unsecured home systems that have not been configured and are still using default SSIDs.

    Note

    Windows Server 2003 Active Directory schema must be extended to handle new wireless group policy settings.

  • Better group policy application over wireless scenarios. In previous Windows versions, many group policy settings would not apply over wireless connections.

  • As discussed previously, when no preferred networks are found, Vista creates a random SSID wireless network on the client (as before), but the client will be placed in passive listening mode and does not broadcast its new random SSID. Inbound connections are not allowed.

  • WPA2-Enterprise connections can be integrated with 802.1X Network Access Protection services.

  • Default security protocol for 802.1X wireless connections is PEAPMSCHAPv2. Prior Windows versions used weaker EAP-TLS.

  • Enhanced EAP architecture (called EAPHost) allows additional EAP types to be added more easily, allows network discovery, and will allow multiple EAP methods and vendors to co-exist without overwriting the other.

  • Command-line interface for wireless configuration (i.e., Netsh wlan).

  • Improved wireless diagnostics tools, APIs, and event logging.

If you want more information on Vista's new wireless security improvements, visit http://www.microsoft.com/technet/network/evaluate/new_network.mspx.


Securing Wireless Networks

Despite all the wireless threats, there are many standard ways to secure Wi-Fi networks. To combat the vulnerabilities listed previously, administrators can implement one of the following common security options, listed from weakest to most secure:

  • 802.11 Legacy Wireless Security Recommendations

  • WEP

  • VPN Protocols

  • WPA

  • WPA2/802.11i

802.11 Legacy Wireless Security Recommendations

In the past, the following security recommendations were often told to wireless network administrators:

  • Change access point's default SSID

  • Enable MAC filtering

  • Disable DHCP on the access point

  • Require user authentication passwords

  • Turn off SSID broadcasting

  • Change an access point's default administrator password

While each of these options could provide some security, each of them is easily bypassed by a minimally knowledgeable wireless hacker. They are listed in order of growing security importance.

Changing Access Point's Default SSID

Most access points come with a default SSID as pre-configured by the vendor (for example, dlink, linksys). It can be changed from the default to prevent roaming intruders from immediately connecting to the wireless network simply because it matches an existing SSID that the computer previously connected. This has to be the worst advice of all. First, if all the administrator does is change the SSID, the wireless access point will immediately advertise the new SSID. Any passing intruders can immediately detect the new SSID and begin attempting to connect to it. Individuals who recommend this wireless security measure, and it is often recommended, don't understand Wi-Fi networks well. Even so, it is a common usability recommendation, as it allows the user to recognize when they are in the range of a particular known network. If all users kept the vendor's default SSIDs, it is likely that several vendor products would overlap each other, leading to confusion. By changing the default SSID to a unique identifier, the user may be able to easily identify which wireless network is the intended one. However, no user should rely on SSID name alone, as an attacker can easily mimic an SSID to fool the user into connecting to the rogue access point.

Enabling MAC Filtering

Media Access Control (MAC) addresses are used by many network protocols as a basic data-link routing mechanism. In TCP/IP networks, which Wi-Fi networks usually are, MAC addresses are used to route packets from source to destination machines on the same local area network. Most access points, if not all, allow the administrator to define a list of allowed (that is, a whitelist) MAC addresses. Computers with unregistered MAC addresses will not be allowed to access the Wi-Fi network. While there is some value in this defense, MAC addresses can easily be sniffed off wireless networks, and once legitimate values are found, they can be used by intruders to force their way onto the meagerly protected network.

Disabling DHCP on the Access Point

Most wireless nodes are assigned dynamic IP addresses by the access point's DHCP services. It is so common that most users of wireless networks expect it to always be that way. One very weak security trick would be for an administrator to assign valid, static IP addresses to all legitimate nodes. Roaming intruders not in the know would not be assigned a valid IP address as they normally expect, and their connection to the access point would appear broke. Unfortunately, simple wireless sniffing will reveal the valid IP address ranges. A sniffing computer, in promiscuous mode, doesn't need a valid IP address to sniff wireless network traffic.

Requiring User Authentication Passwords

Requiring the user to type in their Windows logon name and password to connect to the wireless network has some value, however, alone, logon credentials could be transmitted in clear text or near clear text. Any intruder sniffing on the wireless network could see all shared data streams and network information.

Turning Off SSID Broadcasting

By default, all wireless access points will frequently broadcast their SSID. Turning off SSID broadcasting has some security value. As Figure 13-10 shows, disabling SSID broadcasting is called Enable Hidden Wireless on the example access point. Many clients, including Windows will have a hard time finding and connecting to non-broadcast Wi-Fi networks. However, hackers have developed techniques and tools to detect these types of networks.

Image from book
Figure 13-10: Disabling SSID broadcasting on access point

Vista has been improved to allow non-broadcast networks to be added to the Preferred Network list. Non-broadcast networks will appear as Unnamed Network in Vista.

Disabling SSID broadcasting was initially thought to provide an additional layer of wireless security, but further analysis has proven this practice to be inadvisable in most cases. This is because while the access point does not advertise its presence, all the pre-configured clients looking for it do. The clients will send out probe packets looking for the "hidden" access point, and a listening attacker can intercept those broadcasts, make a rogue access point with the same name, and attempt to re-direct the clients to the invalid access point.

Allowing SSIDs to be broadcast by the access point puts the security requirement at the access point and its configuration, rather than at the client and its user. A client will not provide a rogue access point with the name of its preferred networks if it is configured to only connect to broadcast SSIDs.

More information as to why non-broadcast SSIDs are not recommended can be found at http://www.microsoft.com/technet/network/evaluate/hiddennet.mspx.

Changing an Access Point's Default Administrator Password

This is a solid security recommendation. Most access points come with vendor supplied default passwords (if any). For example, many D-Link access points come with an administrative logon name of admin with no default password. There are many lists all over the Internet containing every vendor's default logon credential. My favorite site is http://www.phenoelit.de/dpl/dpl.html.

When a new access point is first plugged in and accessed for the first time, its admin password should be changed to something ten characters or longer. Many access points also allow the administrator's logon name to be changed. Do that as well, and securely store both values so they can be retrieved later when needed. Some access points also have a read-only user (often called user). If this type of default account exists, change its password (and name, if possible), as well.

Note

Since the WEP encryption itself may still be cracked, you may find that your wireless access point is used by attackers to mount other attacks, engage in criminal behavior traceable back to your network, or simply deny you the bandwidth for which you have paid.

WEP

Wired Equivalent Privacy should be used as a last resort, as a fallback position when legacy components are involved. If WEP must be used, enable 128-bit (or 256-bit) keys. The WEP shared key should be random or complex, and not contain whole words that can be found in the dictionary. If the components allow it, choose Dynamic WEP, an improved WEP protocol where the keys are dynamically updated at frequent intervals. Unfortunately, even the latest, strongest versions of WEP are not as strong as WPA or WPA2 (used with appropriate settings, of course).

Because a primary means of attacking WEP is to capture enough packets to crack the encryption, a protection mechanism you can use, if WEP is required, is to issue a new WEP key frequently. The frequency of change will depend on how much traffic is sent across the network-a fully saturated network might be crackable if its WEP key is not changed every few hours. A home network might be able to get away with changing the WEP key every few days or weeks. The more frequent the change, the better. Some of the newer WEP protocols (called dynamic WEP), can change the WEP key every few minutes. However, whenever possible, WEP, no matter how updated, should be abandoned in favor of new wireless protection protocols.

VPN Protocols

Consider using an external point-to-point client VPN protocol, such as SSL, IPsec, or a third-party VPN product, if all you have is WEP. You can set the access point to WEP or weaker security, but require an authenticated point-to-point VPN connection in order for clients to access any resources beyond the access point. This will provide protection to each client's personal data stream, and stop external sniffing and man-in-the-middle attacks.

Using WPA

The WPA2 standard gained final approval in 2006. Many older network cards and access points do not support WPA, although some will with a firmware or software upgrade. If your Wi-Fi components support WPA, but not WPA2, enable WPA with a long and/or complex pre-shared key. Weak pre-shared keys can still allow any protocol using them to fall prey to successful attacks.

Using WPA2/802.11i

All Wi-Fi administrators, whether at home or at work, should be working toward implementing WPA2/802.11i. WPA2 Personal, with its pre-shared key, is stronger than WEP, and just as easy to setup. WPA2 Enterprise has more difficult setup requirements, but using an appropriately configured PKI service can make certificate distribution easier than most administrators can imagine. Microsoft Certificate Services can distribute computer and user digital certificates automatically as soon as the computer or user logs on successfully for the first time.

WPA2 can also be used without digital certificates, using PEAP-MSCHAPv2. But the best Wi-Fi security that can be had is using WPA2 with smart cards and separate PIN. Two factor authentication using digital certificates should prove to be the most resistant to attack wireless protection currently available. And if the user or computer loses its authority, the Certificate Services administrator can revoke the digital certificate and the wireless node can no longer connect to the network.


Summary

Wi-Fi wireless networks are very popular in today's workplaces and home environments. Most access points and nodes do not come enabled with any default security. Without implementing appropriate security protections, wireless networks can be successfully penetrated and attacked. Windows Vista comes with over a dozen wireless security improvements. WPA2/802.11i and 802.1X authentication are the strongest protection choices available for Windows and Wi-Fi networks.

Chapter 14 will discuss the major new group policy settings available in Windows Vista.


Best Practices

Administrators managing wireless networks should follow these best practice guidelines:

  • Use the strongest wireless protection technology/protocol possible (WPA2, 801.x, and so on).

  • If WPA/WPA2 Personal is used, the shared network key should be long and complex.

  • Change the default administrator password on the access point, and make the new password longer than nine characters.

  • Keep wireless client software and wireless drivers patched and up-to-date.

  • Consider the potential "leak" of wireless network transmissions when designing wireless networks.


Part V: Group Policy and Best Practices

Chapter List

Chapter 14: Using Group Policy
Chapter 15: Thinking about Security
Appendix A: Building a Windows PE Boot Disk
Appendix B: References


Chapter 14: Using Group Policy

Group Policy… The mere mention of it stirs up strong feelings in seasoned Windows administrators. Typically the reaction is some mixture of awe, revulsion, and resignation. Group Policy is a mixture between dark arts, defense against the dark arts, and your ordinary, run-of-the-mill mystery.

It is no small wonder really. Microsoft's Group Policy Reference for Windows Vista, lists 2,494 (!) settings across 131 administrative templates. To that we need to add at least 163 security settings, plus an arbitrary number of configured restricted groups, services, and registry and file system ACLs. It would be quite easy for even a moderate size enterprise to have thousands of Group Policy settings across tens of templates.

Group Policy can certainly be daunting. In this chapter, we discuss the changes to Group Policy in Windows Vista. The reader who is not familiar with Group Policy is warmly recommended to consult Jeremy Moskowitz's excellent book on the topic, Group Policy: Management, Troubleshooting and Security, which is fully updated for Windows Vista. There is so much to discuss that, for efficiency, we will assume an operating understanding of Group Policy. If you feel rusty you may want to brush up on Group Policy either with Moskowitz (at http://www.GPanswers.com), or by perusing some of the documents on Microsoft's Group Policy tech center.

Windows Vista is seeing the most significant upgrade to Group Policy since its introduction with Windows 2000. In this chapter, we discuss the new and updated features, as well as a selection of the 812 new Group Policy settings and all new and modified security settings in Windows Vista and programs that first shipped with Windows Vista.

New Group Policy Features

By far the most significant change in Group Policy in Windows Vista is not all the new settings, although those are certainly very interesting. The most significant changes are in the new features. The first, and most intriguing of these, is that you can now have several local policies on a single computer.

Multiple Local Group Policies

Windows Vista adds support for multiple local Group Policy objects (MLGPOs). This permits you to set different settings for different types of users on a standalone computer, just like you can on a domain-joined computer. There are three types of local Group Policy objects (GPO):

  • Local Computer Policy

  • Administrators and non-administrators group policy

  • User-specific local group policy

The Local Computer Policy is identical to the one in earlier versions of Windows. If you simply open GPEdit.msc, the Group Policy Editor, it will open the Local Group Policy object. Changes you make there will affect every user on the computer, and can also affect the computer settings (which also affect every user).

The other two types of local GPOs support only user configuration and are designed to let you control users settings for different types of users. The administrators and non-administrators Group Policy type lets you set different settings for administrators and non-administrators. The user-specific Group Policies let you set different settings for different users or groups of users.

The only object that exists by default is the Local Computer Policy. The others are created only when you add something to them. To create and manage these objects you need to open a new instance of the Microsoft Management Console (MMC) and add the requisite objects to it. To do so, do the following:

  1. Launch mmc.exe.

  2. Accept the UAC elevation prompts.

  3. Click Fileﾀﾀ Add/Remove Snap-ins.

  4. Add the Group Policy Object Editor.

  5. In the Select Group Policy Object dialog box ensure that Local Computer is selected and click the Finish button.

Image from book
ELEVATION

Remember from Chapter 4 that all administrative operations in Windows Vista require elevating to a process token that includes the administrator's security identifier (SID). Most everything we do in Group Policy is going to be an administrative task. You may want to launch a command prompt as an administrator and then launch gpmc.msc and the other tools from there to avoid getting prompted for all of them.

Image from book

This adds the Local Computer Policy GPO. If you want additional local GPOs, repeat Steps 3–5 for each object you want. However, instead of selecting Local Computer, click the Browse button, and select a group or a user. For example, if you want to manage policy for Administrators, click the Browse button and select Administrators as shown in Figure 14-1.

Image from book
Figure 14-1: Create a GPO for a different user by selecting it in the Browse dialog box.

You can add as many of these Group Policy objects as is practical for you to manage. Keep in mind, however, that Group Policy grows in complexity as you add objects. It is a wise process to start with a general policy that is assigned to everyone, and then assign deltas in more granular policies. This simplifies administration. In practicality, you probably won't add a whole lot of policies because unlike domain Group Policy, MLGPOs do not actually filter policies based on arbitrary groups, other than the Administrators/Non-Administrators groups. You can only create policies for users.

Once you have added all the policies you need, you should save your MMC console so that you can easily go back and manage all the objects. If you do not save it, you may find yourself hunting for policies. Also remember that you can only manage computer policy in the Local Computer Policy object. The console makes that quite clear, however, as shown in Figure 14-2.

Image from book
Figure 14-2: You can add several local GPOs to a single console.

To delete an object you would go through the same steps as you would to add it. However, in the browse dialog box, when you see the list of available objects, right-click the one you want to delete and select Remove Group Policy Object, as shown in Figure 14-3.

Image from book
Figure 14-3: To delete a local Group Policy object, follow the same steps you used to add it and right-click the object name.

Group Policy Precedence

Determining which object's settings will apply can be quite complicated in Group Policy. As with domain-based Group Policy, the most recently applied setting wins. The settings are applied in the order they are listed in Figure 14-2. Local Computer Policy applies before administrator/non-administrator policy, which is applied before user policies. Since policies for groups are not supported, this application order is completely unambiguous. Should you wish to troubleshoot policies, you can also use the Resultant Set of Policy (RSOP) tools, rsop.msc and gpresult.exe. This is shown in Figure 14-4 and the following, abbreviated command-line output:

     C:\Windows\system32>gpresult /z
     Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
     Copyright (C) Microsoft Corp. 1981-2001

     Created On 1/16/2007 at 11:24:41 PM

     RSOP data for JJ-VistaRTMTst\Jesper on JJ-VISTARTMTST : Logging Mode
     ---------------------------------------------------------------------

     OS Configuration:            Standalone Workstation
     OS Version:                  6.0.6000
     Site Name:                   N/A
     Roaming Profile:             N/A
     Local Profile:               C:\Users\Jesper
     Connected over a slow link?: No

     COMPUTER SETTINGS
     ------------------
     <snip>

     USER SETTINGS
     --------------

         Last time Group Policy was applied: 1/16/2007 at 10:51:11 PM
         Group Policy was applied from:      N/A
         Group Policy slow link threshold:   500 kbps
         Domain Name:                        JJ-VistaRTMTst
         Domain Type:                        <Local Computer>

         Applied Group Policy Objects
         -----------------------------
             Local Group Policy\Jesper
             Local Group Policy\Administrators
             Local Group Policy
     <snip>
         Resultant Set Of Policies for User

         -----------------------------------
     <snip>

             Administrative Templates
             ------------------------
                 GPO: Local Group Policy\Jesper
                     KeyName:      Software\Policies\Microsoft\Windows\
     Task Scheduler5.0\Task Creation
                     Value:        1, 0, 0, 0
                     State:        Enabled

                 GPO: Local Group Policy\Administrators
                     KeyName:      Software\Policies\Microsoft\Windows\
     Task Scheduler5.0\Task Creation
                     State:       disabled

                 GPO: Local Group Policy
                     KeyName:      Software\Policies\Microsoft\Windows\
     Task Scheduler5.0\Task Creation
                     Value:        1, 0, 0, 0
                     State:        Enabled
     <snip>
Image from book
Figure 14-4: The Resultant Set of Policy tools also work with MLGPO.

In general, rsop.msc is more user-friendly and is the best tool to use if you want to find out what the ultimate state of a particular setting is and which policy it came from. It also shows the precedence order, as shown in Figure 14-4. Gpresult.exe is useful if you wish to have text-based output for saving to logs, or sending to others, or if you belong to that group of august curmudgeons who still believe that the only good GUI is one that doesn't get in the way of rapidly finding a good command line.

Using MLGPOs in a Domain Environment

MLGPOs can also be used on domain-joined computers, although it is not really recommended for that scenario due to the difficulty of centrally managing the policies. If it is used in a domain environment, the precedence order does not change from prior versions of Windows. All local GPOs are applied before domain-based GPOs. In other words, if a local GPO defines a particular setting to some value and a domain GPO that applies to the same user or computer defines it to some other value, the domain GPO will be the effective value.

To avoid conflicts altogether, or to exercise additional control, you can disable local GPO processing entirely on domain-members by enabling the "Turn off Local Group Policy objects processing" setting in Computer Configuration\ Administrative Templates\System\Group Policy. Obviously, this setting will only apply the next time local GPOs are about to be processed.

For more information on how to manage Multiple Local Group Policy Objects, see the step-by-step guide: http://www.technet2.microsoft.com/WindowsVista/en/library/1033.mspx?mfr=true.

Difference between Local GPOs and Domain GPOs

There are a few differences between local GPOs (LGPO) and domain-based GPOs in terms of the settings they support. There are notably fewer security options in the LGPOs, largely because certain areas of security management are not meaningful on non-domain joined systems. In addition, some features that are exclusively, or predominantly, designed for domain environments, such as Folder Redirection, Remote Installation Services (RIS) (on pre-Vista machines) or Group Policy Software Installation are not supported on LGPOs. In general, MLGPO is primarily useful to administrators of systems that cannot use regular Group Policy. The output of the Group Policy Object Editor is a .pol file. The .pol file is stored in the netlogon share of all Domain Controllers (DC) for domain-based GPOs. Local Group Policies are stored in various places. Administrative template settings in the Local Computer GPO are stored in %systemroot%\System32\GroupPolicy\Machine\Registry.pol and %systemroot%\ System32\GroupPolicy\User\Registry.pol. User and group specific local policies are stored in %systemroot%\System32\GroupPolicyUsers\<SID>\User\Registry.pol.

New Administrative Template Format

Administrative templates are definition files that drive the user interface (UI) in the Group Policy Object Editor. They define which settings can be configured, what values they take, which UI elements are available to edit them, strings to help the administrator understand what is being edited, and so on.

In Windows Vista, Microsoft replaced the aging administrative template file format, ADM, with a new XML-based file-format: ADMX. The ADM template format has been used, with a few updates, since the Windows 95 System Policy Editor. ADM was really just an updated version of that format. The group policy file itself, the .pol file, is still essentially equivalent to the old System Policy Editor output files.

The new file format was created at least in part to support Microsoft's initiative to lower costs associated with localization. Windows XP was fully localized into 24 languages, and partial localization is available in an additional 33 languages. Needless to say, the cost of localization can be significant, especially if the user interface text elements are spread throughout a large number of files. In addition, any change in the text would require complete rebuilding of all affected components. Finally, localization cannot proceed until the code is mostly written because the text elements that are part of the code need to be complete before they can be localized. To simplify and manage this process better, and to enable simultaneous shipping of Windows in multiple languages, Microsoft has separated much of the text elements from the code elements that use them. This means that developers can define their text elements early on and send those out for localization. They can then proceed to write the rest of the code, while the text is being translated. This is a significant security benefit for many users that do not use English versions of the operating system. In the past, it was quite common for Microsoft to ship a service pack in only three languages (typically English, German, and Japanese) with all other service packs to follow over a span of one to six months. However, the errata, lists of all bugs fixed, were published when the original versions were released. This gave attackers a significant advantage. They had complete details on bugs, and even code that was fixed to compare with code that was vulnerable. Customers using other language versions of the product, however, had no patch available to them.

The ADMX file format actually consists of two separate files: an ADMX template that defines the UI elements, and an ADML file that contains localized versions of all strings used in the ADMX template. The new format is more flexible and provides additional control elements. It also handles versioning much better than the old ADM format. For more information on the schema see Microsoft Corporation, 2007b.

Template Embedding

One very simple, but welcome change in GPO in Windows Vista is how the ADMX templates are treated with the policies. Ever since Windows 2000, each GPO has contained a copy of all the ADM templates that were used to create it. For an organization with a large, complex GPO structure, that means that the system.adm template could be replicated in hundreds of policies, creating significant replication overhead.

When building policies with ADMX templates, you may use a central store of ADMX templates instead. This is not done automatically for you to avoid impacting down-level DCs. To create the central store you would create a directory called PolicyDefinitions in the %systemroot%\SYSVOL\domain name\Policies directory of your DC. You can then copy the ADMX and ADML files from the %systemroot%\PolicyDefinitions directory on a Windows Vista member workstation. Note that the ADML templates are language-specific. For instance, the U.S. English ones are in a subdirectory called EN-US. You should copy all the ones that relate to languages you will use to manage Group Policy, but it is not necessary to copy ones that are used on clients that receive the policies, but are not used to manage them. For instance, if you manage a network where about 80 percent of the workstations are localized in Swedish, but the administrative workstations are using U.S. English versions of the OS, you will need to copy only the U.S. English versions. The policies themselves are language independent and work across all languages.

After you have copied the administrative templates to the sysvol share the Windows Vista Group Policy Editor will automatically use templates from the central store instead of the local copies when editing domain-based GPOs. Note that pre-Vista operating systems have no knowledge or recognition of the central store. This ability only comes with Windows Vista (and presumably Windows Longhorn server) when being used to edit your Group Policy Objects.

Migrating to ADMX

If you are interested in migrating existing ADM templates to ADMX this can be done. Microsoft has published the ADMX migration tool which can be used to convert templates from ADM to ADMX. For more details, see http://www.go.microsoft.com/fwlink/?LinkId=77409.

Client-Side Pulling and Network Location Awareness

In the past Group Policy relied on the Internet Control Message Protocol (ICMP). Clients used ICMP ECHO (ping) to locate domain controllers and detect slow links. Starting with Windows Vista, this functionality is provided through Network Location Awareness (NLA) instead. This means that clients will more reliably get Group Policy applied and that administrators who block ICMP for security reasons will still be able to use Group Policy.

In addition, Group Policy settings are now applied whenever domain controller availability returns. Starting with Windows Vista clients pull policy whenever a connection event occurs; such as after resuming from suspend mode (but only if the client missed the last update).

Image from book
GROUP POLICY APPLICATION INTERVALS

Many people are not aware how often Group Policy is reapplied under normal operations. The method of doing so differs depending on where in Group Policy the settings are. Every 90 minutes, with a positive variance of 30 minutes, the client computer polls the domain controller for changes to the version numbers of the GPOs that affect it. If the version number has changed, settings that are stored in the registry.pol file, such as all settings in Administrative Templates and the Windows Firewall with Advanced Security nodes, are reapplied. If the version number has not changed, the client does not reapply any settings. If the client cannot locate the domain controller at the time it is supposed to, the counter resets and it tries again in 90 minutes.

Every 16 hours the client retrieves the settings stored in GptTmpl.inf, including all settings in the Security Options branch, and reapplies those.

Both of these intervals are dependent on whether the client can find the domain controller. If a Windows XP client is not able to locate the domain controller when the GptTmpl.inf settings are to be re-applied it will simply reset the counter to another 16 hours and try again then.

The change in Windows Vista is that a client will poll for Group Policy as soon as it finds a domain controller. Prior versions of the OS would poll only when the timer was up next time. Settings in GptTmpl.inf will be reapplied when NLA reports that a DC is available again, and settings in registry.pol will be reapplied if the version number of the GPO has changed.

Image from book


Updated Group Policy Features

Many features in Group Policy were also updated in Windows Vista. Some of these are quite significant from a security perspective, and others are simply nice additions to the toolset.

Group Policy Management Console v. 2.0

If you have not used the Group Policy Management Console (GPMC), you need to start-soon. It hugely simplifies management of GPOs in a complex environment. For one thing, it lets you see all the GPOs in the environment without having to hunt through tens or hundreds of OUs, sites, and domains.

Microsoft originally made the GPMC available as a download. In Windows Vista, they actually included it with all editions of the operating system that can join a domain. It does not have an icon, but if you click the Window button and type gpmc.msc in the search dialog box you will find it. The GPMC is shown in Figure 14-5.

Image from book
Figure 14-5: Using the GPMC, you can get an at-a-glance view of the GPOs in your domain.

Note that only the version of gpmc.msc included in Windows Vista (and, naturally, Windows codename Longhorn, when it ships) supports the new ADMX templates and the central store. This is the major addition to GPMC in version 2.0.

Internet Explorer Management Without IEAK

Previous versions of Windows did support fairly extensive management of Internet Explorer but only by using the Internet Explorer Administration Kit (IEAK). The IEAK was always a separate download and allowed administrators to do everything from pre-configuring the proxy servers to replacing the little icon used to signify that the browser is retrieving a page.

In Windows Vista, as shown in Figure 14-6, a relatively complete set of management features for Internet Explorer is included in Group Policy.

Image from book
Figure 14-6: You can now manage much of Internet Explorer using Group Policy.

Many of the settings for Internet Explorer are available both under Computer Configuration and User Configuration, meaning they can be set for the entire computer, or just for a user. Computer settings in Internet Explorer overrule user settings. In other words, if you disable the popup blocker under Computer Configuration, but enable it for particular users under User Configuration, it will remain disabled. This precedence does not necessarily apply to other settings. It is quite possible that a setting made under User Configuration overrules or modifies a setting made under Computer Configuration. It is up to each application to interpret these settings as they see fit. Some make the decision that computer configuration is more important; others opt for the approach that users modify the function specified for the computer. If you are using Administrative Templates settings for security purposes, it is imperative that you verify that the settings you make have the intended effect.

In Chapter 8, we discuss the settings you can use to protect Internet Explorer in much more detail.

Group Policy Application Factored from Winlogon

Prior to Windows, Vista Group Policy was applied within the Winlogon process. Winlogon is responsible for a lot of things, including getting users logged on and ensuring that the user's desktop gets loaded. Group Policy is now handled through its own service, the Group Policy Client.

The Group Policy Client service has a very restrictive ACL associated with it to prevent administrators from accidentally disabling it. A malicious user with physical access to the computer, or an administrative account, can of course both stop the service and delete it. The ACL on the service cannot protect against administrative attacks, but it is worth noting how Microsoft has started making it a bit harder for administrators to destroy their systems. It took one of the us almost 5 minutes to stop the Group Policy application by deleting the Group Policy Client from a test computer. Of course, we needed local administrative access to perform this. Standard Users cannot stop Group Policy application.

Group Policy Logging Moved to System Event Log

Since Group Policy application was moved to its own service, all we once knew about troubleshooting Group Policy isn't applicable. We no longer need to use the userenv.log file to troubleshoot Group Policy. Group Policy events now go into the Windows event logs. The system event log now will contain the administrative events that were in the application event log in prior versions of Windows.

Operational events, such as those that were previously found in the userenv.log file, are now in the Group Policy operational log, as shown in Figure 14-7.

Image from book
Figure 14-7: Group Policy operational events are now in the event log.

In general, it is a good thing that Group Policy is finally a first-class service. The really big benefit, from a security perspective, however, is the event logging. Now that the events are in the event logs they can be managed centrally much more easily. This means that you can audit Group Policy application and failures, and fulfill regulatory requirements with respect to configuration much more easily.

Moving all of the Group Policy information to the event logs means we need to change how we troubleshoot Group Policy problems though. There are lots of new events to learn, and to search. Microsoft has published a relatively comprehensive white paper on how to troubleshoot Group Policy using the event logs.


New or Updated Group Policy Settings

Now that we have a handle on the new features in Group Policy in Windows Vista, let's turn our attention to the things that really matter: the knobs! There are lots of new knobs, dials, buttons, and switches that we can use to turn on security, and just to pass an afternoon after we locked everyone else out from doing their jobs.

In this section we will go over a selection of the new settings. As mentioned earlier, there are almost 1,000 of them. There are relatively few new security options, however. These are the settings under Computer Configuration\ Windows Settings\Security Settings\Local Policies\Security Options. These are important because they are enforced even if the central policy has not been changed. They are also reapplied consistently, not only when the version number changes as with regular Group Policy. Therefore, we will go through all the new security options, as well as those that have been modified from Windows XP, and the few that are removed.

New Security Options

Table 14-1 shows the new security options and their default values.

Table 14-1: New Security Options in Windows Vista Open table as spreadsheet
NAME | DEFAULT VALUE | NOTES
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings | Not defined | This setting configures how Windows Vista interprets the audit sub-category settings configured with auditpol .exe. The default behavior is to override sub-category settings with the category settings, which requires Group Policy changes for the sub-category settings to be used. If this setting is set to "enabled" the sub-category, settings will take precedence over the category settings.
Interactive Logon: Display user information when the session is locked | Not defined | Some organizations are considerably more paranoid than others and find it an unacceptable risk to display the last logged on user in the logon dialog box. However, when a user is logged on but the console is locked, the username is shown on the screen. This new setting permits those organizations to configure the computer not to show the username on the logon screen at any time.
Network Access: Remotely accessible registry paths and sub-paths | System\CurrentControlSet\Control\Print\Printers System\CurrentControlSet\Services\Eventlog Software\Microsoft\OLAP Server Software\Microsoft\Windows NT\CurrentVersion\Print Software\Microsoft\Windows NT\CurrentVersion\Windows System\CurrentControlSet\Control\ContentIndex System\CurrentControlSet\Control\Terminal Server System\CurrentControlSet\ | This setting was actually added in Windows 2003. Prior to Windows Server 2003, there was no way to specify whether a registry key and all its sub-keys or just the key itself were to be accessible accessible remotely. To close a vulnerability caused by that limitation in Windows 2000, the semantics of the "Network Access: Remotely accessible registry paths" setting were changed in Windows Server 2003 to only make the key specified accessible remotely.
Network Access: Remotely accessible registry paths and sub-paths | Control\Terminal Server\UserConfig System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration Software\Microsoft\Windows NT\CurrentVersion\Perflib System\CurrentControlSet\Services\SysmonLog | The "Network Access: Remotely accessible registry paths and sub-paths" setting was added with the same semantics as the old setting had in Windows 2000 and Windows XP.
System cryptography: Force strong key protection for user keys stored on the computer | Not defined | This setting is used to configure whether users have to use a password to access private key certificates. By default, the setting is not defined. This means that each certificate can define its own protection level.
System settings: Optional sub-systems | Posix | This setting is not at all new. It has existed in every version of Windows that has supported multiple sub-systems. However, it has never been present in Security Policy before.
System settings: Use certificate rules on Windows Executables for Software Restriction Policies | Disabled | Normally you cannot use certificate rules to restrict execution of Windows binaries using Software Restriction Policies (SRP). This setting can enable that behavior.
User Account Control |  | There are nine User Account Control polices built in. These were covered in Chapter 4.

Security Options with Modified Defaults

There are also a few security options that have different defaults than they had in Windows XP. The following list shows which options are affected and the old and new defaults.

Table 14-2: Security Options with Modified Defaults in Windows Vista Open table as spreadsheet
NAME | WINDOWS XP DEFAULT | WINDOWS VISTA DEFAULT | NOTES
Accounts: Administrator Account Status | Enabled | Disabled |
Devices: Allowed to format and eject removable media | Administrators | Not Defined | This is no net change in the setting. The default value is Administrators if the setting is not defined.
Devices: Restrict CD-ROM access to locally logged on user only | Disabled | Not Defined | This is no net change. The default behavior is disabled if the setting is not defined. Please note that this setting applies only if (a) there is a CD in the drive, and (b) a user is currently logged on, and (c) the drive has been shared out. If any of those conditions do not hold this setting has no effect at all.
Devices: Restrict floppy access to locally logged on user only | Disabled | Not defined | Same notes apply as for the CD-ROM setting listed previously.
Interactive logon: Require smart card | Not defined | Disabled | This is simply a clarification. The default state of the setting was always disabled.
Network Access: Named Pipes that can be accessed anonymously | COMNAP, COMNODE, SQL\QUERY, SPOOLSS, LLSRPC, browser | netlogon, lsarpc, samr, browser | There are still a few named pipes that are anonymously accessible by default, but many of the old ones have been removed, including the SQL\QUERY pipe, which has not been needed for many years.
Network Access: Remotely accessible registry paths | System\CurrentControlSet\Control\ProductOptions System\CurrentControlSet\Control\Print\Printers System\CurrentControlSet\Control\Server Applications System\CurrentControlSet\Services\Eventlog Software\Microsoft\OLAP Server Software\Microsoft\Windows NT\CurrentVersion System\CurrentControlSet\Control\ContentIndex System\CurrentControlSet\Control\Terminal Server System\CurrentControlSet\Control\Terminal Server\UserConfig System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration | System\CurrentControlSet\Control\ProductOptions System\CurrentControlSet\Control\Server Applications Software\Microsoft\Windows NT\CurrentVersion | This setting was changed mostly because of the introduction of the "Remotely accessible registry paths and subpaths" setting. The entries in here, which includes the very important Software\Microsoft\Windows NT\CurrentVersion have been suitably restricted. The remainder have mostly been moved and are treated the same as they were in Windows XP.
Network access: Shares that can be accessed anonymously | COMCFG, DFS$ | Not Defined | It seems logical and good that there are no longer any shares accessible anonymously. However, Windows clients never had a DFS$ share-only servers that were running DFS had that. Windows Vista does include DFS but
 |  |  | the DFS$ share does not exist. COMCFG is created by Microsoft's Host Integration Server (formerly SNA Server). It is quite unlikely that this share will exist on clients as well. Therefore, the net change here is nil.
Network security: Do not store LAN Manager hash value on next password change | Disabled | Enabled | This setting has limited security value, but huge symbolic value! For the very first time, Microsoft has turned off an extremely old and widely discredited (from a security perspective) protocol. It is an all around positive change.
Network security: LAN Manager authentication level | Send LM & NTLM Responses (Level 0) | Send NTLMv2 response only (Level 3) | Just as with the LAN Manager hash setting, this setting marks a departure whereby Microsoft has chosen security over backward compatibility, but unlike LAN Manager hashes, this one actually has a positive security impact. This setting prevents the use of three old, and insecure by today's standards, protocols for outbound authentication. It is a very positive, and long overdue step in the right direction. This setting means Windows Vista cannot connect to Windows 9x servers hosting shares, unless the Windows 9x server can pass the authentication off to a domain.

Removed Security Options

Table 14-3 shows which security options were removed in Windows Vista.

Table 14-3: Security Options That Were Removed in Windows Vista Open table as spreadsheet
NAME | NOTES
Devices: Unsigned driver installation behavior | This setting was more or less useless. The proportion of signed to unsigned 32-bit drivers is somewhere in the ratio of 5:95. Microsoft should have barred unsigned drivers from the beginning and it would have alleviated many problems, including the rootkit issue. On the x64 platform, where Microsoft got a chance to start over, unsigned kernel drivers are not allowed.
System objects: Default Owner for objects created by members of the Administrators group | This setting controls who is the owner of objects created by members of the administrators group. In early versions of Windows NT, the Administrators group was the owner of any object created by members of the Administrators group. This behavior changed in Windows 2000, but was controllable via Group Policy. Now the setting has been removed altogether. The user that created the object becomes the owner of it.

New Administrative Template Settings

In contrast to the relatively few changes made to the security options, there are so many administrative template settings that we could probably devote the entire book to them and still not do all of them justice. We highly encourage you to explore on your own, particularly using the list of group policy settings in Windows Vista that we mentioned earlier. By sorting the spreadsheet you can see very easily which settings are new.

In this section we will focus on some areas that we find interesting and important from a security perspective, and that are not covered in other chapters. For instance, Internet Explorer is covered in Chapter 8 and Windows Firewall is covered in Chapter 11. No doubt you can find security-relevant settings sprinkled throughout other areas of Group Policy. It is quite interesting that Group Policy, in many ways, is getting so large and complex that it may already have more settings than the original registry that it was in part designed to abstract!

Attachment Manager

The Attachment Manager was introduced in Windows XP Service Pack 2 (SP2). The Attachment Manager provides a set of Application Programming Interfaces that applications that deal with attachments, primarily mail clients, can use to ensure consistent security controls are applied to those attachments. The Attachment Manager settings, shown in Figure 14-8, can be used to configure the risk level for specific file types as well as how antivirus programs are notified of attachments. The settings are available only in User Group Policy.

Image from book
Figure 14-8: Attachment Manager settings in Group Policy

Antivirus programs can register themselves with Attachment Manager and will then receive notification any time attachments are opened. This enables them to use documented and stable ways to intercept attachments, instead of the traditional way of attempting to hack up the mail clients. It is also Attachment Manager that causes the popups when you execute a downloaded file because a downloaded file is treated just like an attachment. Attachment Manager preserves the Internet Explorer security zone the file came from within the file metadata in an alternate data stream. This behavior can also be configured in Group Policy. If you remove the alternate data stream, by, for instance, copying the file to a USB key formatted with FAT32, you lose the Attachment Manager protection.

Printer Deployment

Using the Package Point and Print functionality introduced in Windows Vista, administrators can relatively easily deploy printers to users. Using the settings under User Configuration\Administrative Templates\Control Panel\Printers, you can also restrict users to only using Package Point and Print servers.

Print drivers are very often kernel mode drivers and have full access to everything on the computer. This means that installing print drivers is a highly privileged operation. Package Point and Print is the latest mechanism Microsoft has developed to make printer installation easier and not require all end-users to be administrators. Jeremy Moskowitz has a great how-to article on his Web site (http://www.gpanswers.com/newsletters/17).

Device Installation

After the release of the movie "The Recruit," administrators seemed to become inordinately concerned with users' ability to connect USB flash drives and steal sensitive data on them. Notwithstanding the fact that hardly anyone needs the same level of security as the Central Intelligence Agency, and the fact that while almost everyone was concerned about USB flash drives, few companies installed metal detectors at the exits. Microsoft did something about the situation. The new device installation settings are shown in Figure 14-9.

Image from book
Figure 14-9: Windows Vista permits administrators to control device installation.

Device installation restrictions are done based on device IDs or device classes, shown in Figure 14-10. There are both whitelist and blacklist settings for both types of restrictions. Obviously, blacklisting device IDs is an entirely pointless, but potentially very time-consuming exercise. Each device may have a unique ID, and the ID can typically be modified using less than $15 of electronic parts and third-year college level electrical engineering skills.

Image from book
Figure 14-10: You can whitelist specific devices or entire classes of devices.

The only meaningful restrictions are whitelists, but those, of course, require a tremendous amount of work to develop a list of all the devices/device classes to permit. The level of user-pain involved is quite significant, as well as inevitable. Some devices will not make it into the first few iterations of the list.

Microsoft published a lengthy (20 pages) white paper with a step-by-step guide for how to use the new device installation restrictions. It shows how to restrict a device based on device ID, but unfortunately the information on how to find device class GUIDs was left out. These are listed in the MSDN Library.

A slightly more useful, or at least easier-to-implement, solution, is to ban writing to removable media. This can be done using the Removable Storage Access setting under Computer Configuration\Administrative Templates\System.

Keep in mind when considering whether to manage devices that you are inherently trying to restrict what some, potentially evil, person with physical access to a computer can do to that computer. With physical access, that person can do anything! Restricting device installation is nothing more than trying to restrict what authorized personnel can do with data that they are authorized to access and use. The proper way to restrict that is in the data itself. Data needs to be responsible for its own protection. It cannot rely on a device using a specific driver or a certain device ID. If you really need to restrict data, look at a way to persist protection with the data, such as the solution from Avoco Secure (http://www.avocosecure.com/), or Microsoft's Rights Management.

Remote Procedure Call

After the Blaster worm came out, Microsoft started providing administrators with more control over how the COM and RPC interfaces on computers behaved. These settings were primarily added in Windows XP SP2, and are available in Computer Configuration\Administrative Templates\System\Remote Procedure Call. For the most part, these settings are acceptable at their defaults.

Terminal Services

Windows Vista contains an entirely new Terminal Services client, which is also available down-level. Together with this client comes some new, very exciting security technology. For instance, the client can now validate the identity of the server and can be configured to not connect to servers that do not validate their identities, as shown in Figure 14-11.

Image from book
Figure 14-11: The Windows Vista RDP client can authenticate the server you connect to. Server authentication only works with Windows Vista or higher terminal servers.

The Terminal Services Group Policy settings are in Windows Components/Terminal Services/Remote Desktop Connection Client under Computer Configuration. Some of the same settings are also available as User Configuration settings in the same location. If the same setting is configured in both places, the Computer Setting will prevail. For instance, the setting to permit or block users storing their terminal services passwords is available in both places. As a side-note, the password is stored using the Credential Manager API, which is a quite safe way to store passwords.

The most interesting settings are available in the Terminal Server/Security node in the Computer Configuration section, as shown in Figure 14-12.

Image from book
Figure 14-12: Windows Vista offers several new configuration options, such as the encryption used for RDP sessions.

As shown in Figure 14-12, Windows Vista can specify different encryption algorithms for the RDP connections. Instead of using native RDP encryption, the connection can make use of TLS 1.0 (yes, we are aware of the fact that TLS 1.0 is not the same thing as SSL). Native RDP encryption is not bad, but TLS 1.0 uses industry standard, vetted protocols and is probably a better option.

Using the Device and Resource Redirection node, also shown in Figure 14-12, an administrator can configure whether audio or resource redirection is permitted. This controls whether the client is permitted to make its local devices available inside the terminal services window. In a situation where clients should not be permitted to share data with a terminal server it is important to disable clipboard, ports, and drive redirection.


Settings That Require Reboot or Logon

The vast majority of registry based Group Policy settings (the ones in Administrative Templates) can be modified on the fly, while a user is logged on and working. However, a relatively small number can only be applied at logon, and a few can only be applied at reboot. The number of settings that can apply only at logon or reboot is quite small, compared to Windows XP.

Few of the ones that are only applied at logon have much to do with security. The only ones that are related are the ones relating to logon hours, and specifically, what to do when logon hours expire.

Settings that require reboot include the option to turn off Windows Defender. That can only be done with a reboot. For a complete list of this group, refer to Microsoft's document on how to deploy Group Policy with Windows Vista.

A significantly larger number of settings in the Security Options portion require a reboot. For instance, any setting that would modify a user security token, such as the settings controlling privileges, require a logon for that user since the token is built at logon. If the token is for NetworkService or LocalService this means the system has to be rebooted-those tokens are built when the system boots and the services running with them are started. Other settings have different application times. For example, the setting controlling whether the LM Hash is generated is applied immediately, but only to new passwords set after the setting was modified. Existing passwords are never modified when that setting gets changed.


Windows Vista Security Guide

The day Windows Server 2003 was released, Microsoft released a Security Guide for it. This guide was a staggering success and eventually was accepted as the deployment guide for the United States Department of Defense (DoD) along with other agencies. Following on that success Microsoft released a security guide for Windows Vista on the day Windows Vista was released.

The Windows Vista Security Guide includes several deployment tools, including completed GPOs and OUs that can be installed using a script. These tools were shown in Figure 14-5.

The guide contains two levels of settings: Enterprise Client and "Specialized Security-Limited Functionality" (SSLF). One of the authors was a driving force. Many different names, including some far more colorful ones, were contemplated. The idea was to ensure that the name sounded like a warning signal. The SSLF GPOs are for environments where people will die if the systems get compromised, or where large amounts (billions) of money will be lost, or where nation states will go under. They are meant for military establishments, banks, and similar organizations, most of which cannot actually run with the settings defined in the SSLF GPOs. Think twice before you decide to apply the settings. Even many of the organizations these settings were meant for cannot use them due to problems they cause with printers, scanners, and third-party applications.

Do You Need the Vista Security Guide?

The obvious question people are asking is "do I need to use the Windows Vista Security Guide" to secure my Vista system? Perhaps, the slightly more interesting question is the follow-up question: "If I have to use the guide, why didn't Microsoft make it the default?"

To answer this question, you really need to understand the benefits and drawbacks of the security guide.

What Is Good in the Vista Security Guide

Generally, the audit changes made in the guide are not bad. It is particularly good that the guide enables Process Creation auditing, as this is the only way to audit User Account Control events. The method of implementation of the audit changes-a startup script-is very inelegant, but stems from the fact that Microsoft did not provide a centralized management mechanism for sub-category auditing in Windows Vista.

We also like the fact that Microsoft went to the trouble of publishing the guide in the first place. A properly written guide, with reasonable settings, can give a nice introduction to security risk management. It can be used to reinforce that not everyone can use the same configuration.

What Could Have Been Better in the Vista Security Guide

The use of the GPOs is inelegant to say the least. The Windows 2000 Security Hardening Guide from Microsoft was the first to take a novel approach to security configuration management. It put all settings held in common across all systems into a single GPO. This trend was continued in subsequent security guides from Microsoft, but was broken, with a bang, in the Vista Security Guide. There are hundreds of duplicated settings across the Desktop and Laptop policies. This makes it very difficult to get an at-a-glance understanding of the settings recommended in the guide, and even more difficult to modify them to suit individual needs.

It is strange that the audit settings are set both in the Desktop and Laptop GPOs, even though the auditing used is identical in both. The guide makes 16 changes to the default audit policy in the SSLF configuration, and 10 subcategory changes plus changes to the categories in the Enterprise configuration. There are several odd things about this configuration. First, the guide turns off auditing on events. For instance, Account Lockout events are normally audited, but the guide turns off auditing for them in both configurations. Of course, there should never be any of those events on a client, as they would get logged on the computer hosting the account. That means users of the guide need to ensure they are turned on at the domain level though. Using the settings in the guide, account lockout events will happen, and it probably would be good to have an audit trail. Another oddity with respect to auditing is that the guide specifies category audit settings in the GPO in the Enterprise configuration, but not in the SSLF configuration. That actually means that the Enterprise configuration will have more events audited than the more sensitive SSLF configuration. This is supposedly done because the Enterprise configuration for Windows Vista is designed to work both with Windows Vista and Windows XP. However, it makes it quite difficult to tell what modifications need to be made to a Windows Vista computer.

It is important to note that environments that use Remote Assistance will be unable to use the guide as is. In Chapter 4, we discussed a problem with Remote Assistance and UAC when certain security settings are configured for UAC. The Vista Security Guide makes all the changes that become problems for Remote Assistance.

Another feature of the guide that we dislike is that it enforces a number of default settings. In fact, the guide will modify the Group Policy Editor interface to show a number of settings that are not normally shown, so that the defaults can be enforced. In some cases, there are even settings added to control behavior for which Windows Vista already has settings, but Windows XP does not. This is the case, for instance, with the AutoRun settings, which are available in Windows Vista already under Computer Configuration\Administrative Templates\ Windows Components\AutoPlay Policies. The settings added to the user interface by the guide seem, pretty universally, to have been a cut-and-paste effort from the Windows XP Security Guide, and are often not needed on Windows Vista. The fact that settings were specifically added to control behavior that Windows Vista already controls, clutters the changes the guide makes that actually modify how Windows Vista operates, and makes it hard to analyze whether the guide will work in a particular environment or not.

Enforcing defaults can be valuable, and may be recommended for the environments targeted by the SSLF settings. However, in a highly managed environment, such as the one the guide is intended for, it is typically unnecessary. In fact, it greatly complicates security management because there are now so many more tweaks made that finding the cause of a problem becomes much more difficult. It also gives the impression that the authors of the guide fell prey to that all-too-common ailment of believing that more settings must be better. One of the best ways to fill a guide with settings is to make changes that make no difference, such as enforcing defaults.

Previous security guides from Microsoft have largely adhered to the principle that "less is more" and have only advocated changes that make a significant difference in the operating system. Unfortunately, the Windows Vista guide breaks that tradition. For instance, templates make a large number of settings that are not visible in the GUI. An example is the setting to disallow use of Windows Messenger; it is turned on in both the Enterprise and SSLF configurations. This hardly seems necessary because Windows Messenger was deprecated and does not ship with Windows Vista. The downloadable version will not run. This setting, thus, makes no difference whatsoever and serves only to confuse matters.

Nowhere is the More-Settings-Is-Good syndrome more evident than in the firewall section though. The guide makes extensive changes under Computer Configuration\Administrative Templates\Network\Network Connections\ Windows Firewall\Domain Profile and Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall\Standard Profile. This may be sensible, until one recognizes that those nodes are used to configure the firewall in XP SP2, not the Windows Vista firewall (the settings here will apply to the Windows Vista firewall, but only if the Windows Firewall with Advanced Security settings are not configured, which they are). It is also unfortunate that the guide does not contain usable information on how to replicate the firewall settings made in the templates for those environments that cannot use, or are uncomfortable with using, the templates as they are.

Not recognizing this in the guide, and filling the Group Policies with unnecessary security settings calls into question the wisdom of the advice given in the guide.

Importance of the Guide

The guide can be useful to some customers. However, we are unable to advocate use of this guide as is because of the issues discussed previously. We are disappointed that the guide does not put more emphasis on proper risk management and exhibits traits that are reminiscent of some of the most dangerous security guides available. We recommend that administrators evaluate the guide carefully, in light of their risk management policy. Most environments will almost certainly be fine with the default settings, possibly augmented by a few, judicious, firewall changes and possibly a handful of other settings, based on the organizations risk management strategy.


Active Directory Schema Updates

Windows Vista includes two group policy-related management features that require modification to the Active Directory Schema. One is the new wireless security management features (see Chapter 13). The other is the ability to escrow BitLocker (Chapter 3) and Trusted Platform Module recovery keys in Active Directory. Both of these require schema changes to Active Directories. Those schema changes are fully supported. The complete instructions and the schema itself is included in the respective downloads.


Managing Group Policy in a Mixed Environment

As mentioned earlier, Windows Vista introduces a new administrative template format, ADMX. All settings under Administrative Templates in Windows Vista are defined in these new files. This calls into immediate question what happens to settings for older operating systems, or to Windows Vista, when settings in a GPO were made using an older operating system.

Settings available only in Windows Vista, which includes the 800+ new settings, must be configured using a group policy editor on a Windows Vista computer. The GPO itself can be stored on domain controllers of any type, but the settings can only be made on Windows Vista until the server version of Windows Vista, currently codenamed "Longhorn" ships. For that reason, the recommendation is that administrators upgrade the computer they use to administer Group Policy to Windows Vista early, so that they can manage the Windows Vista settings before the OS goes into broad deployment.

GPOs created with Windows Vista, using ADMX templates, will no longer contain ADM files. As we discussed, you can create a central policy definition store in the sysvol share on the DCs, but pre-Vista systems will not know to go look there. Therefore, a down-level system will show a GPO created on Windows Vista as having only Extra Registry Settings. There are no ADMX templates available to the down-level OS to parse the registry.pol file with.

It is important to note though that you can manage all policy settings using Windows Vista and GPMC 2.0. You do not need to keep a down-level OS around just to manage policies for other down-level computers. A GPO created with Windows Vista may not be displayed properly in GPMC 1.0 or GPEdit on a computer running Windows Server 2003, but the registry.pol file is in the same format it always has been. It will be parsed properly by your down-level computers. The recommendation, therefore, is to perform all your GPO management on a computer running Windows Vista, or one running Windows Server Codename Longhorn-the server version of Windows Vista.

If you have written custom ADM templates you may of course convert those to ADMX, but it is not necessary to do so. The Group Policy tools in Windows Vista will parse and use ADM templates the same way as the tools in earlier operating systems did.

Finally, if you have modified one of the built-in ADM files, such as system.adm, or wuau.adm, you will not be able to leverage the modifications on a computer running Windows Vista. The new group policy editing tools ignore ADM files that have been replaced by ADMX files. In order to use modified ADM files, you would have to use a computer running Windows XP or Windows Server 2003. The better option is to start upgrading those ADM files though, and preferably, factor the custom settings out to a separate file instead of modifying the built-in ones.


Rollout Strategy

Before you start upgrading users to the new OS, the basic recommendation for rollout is to upgrade a few administrative workstations to Windows Vista quickly. This not only lets administrators familiarize themselves with the new OS, it also gives you some place to build and manage group policies for computers running Windows Vista. As of this writing there are Group Policy extensions for some of the Windows Vista settings available for Windows Small Business Server 2003 R2 (http://www.microsoft.com/downloads/details.aspx?FamilyID=). However, there is no update for Windows Server 2003 to support management of Windows Vista specific Group Policy settings. That means you need a Vista workstation to manage the settings.

It is also highly recommended that you plan a schema upgrade for Active Directory so that you can manage wireless settings and use BitLocker key escrow, if you wish to do so. Full hard disk encryption is a worthwhile technology at least on all mobile computers. BitLocker does cost extra though, as it is only available on Enterprise Edition and Ultimate. Evaluate your options, and if BitLocker is your choice, start planning now for how to handle key escrow. Our experience tells us that manual key escrow works fine, until the first VP misplaces his USB flash drive with the key, and needs to get the recovery password.

We also recommend that you do not put Windows Vista settings in the GPOs you use for the existing clients in your environments. Chances are you do not want to have all the same settings apply to them. For example, we ran into trouble in a pilot when we discovered that the existing group policies force deployed McAfee's Host Intrusion Prevent System using Group Policy Software Installation. That particular tool was written to modify parts of the OS that Windows Vista considers it an aggressive act to modify; parts only a rootkit might modify. Consequently, every one of the Windows Vista computers "blue screened" on the first boot after they were joined to the domain. You really want to create separate GPOs, and then, judiciously, port settings that will work on Windows Vista. You can augment them with settings that are specific to Windows Vista.

After you have created your Windows Vista specific GPOs, you should use WMI filters to ensure that they apply only to computers running the new OS. In Chapter 11, we showed how to create such a WMI filter to manage the firewall settings. For your WMI scripting enjoyment, on the Web site for the book, we have a little script that dumps out all OS parameters in WMI. Any, and all, can be used to write WMI filters to ensure that your policies apply only to the right systems. One useful, but often overlooked, parameter is the Product-Type. A product type of 1 indicates a workstation, 2 indicates a DC, and 3 is a server. By putting and ProductType=“1” in your WMI filter, you can ensure your policy applies only to workstations, for instance.

Logon Scripts Fail Because of UAC

Some very common operations may need to be rethought due to the new features in Windows Vista. For instance, UAC will block certain operations in logon scripts because they may require administrative interaction. An example is a logon script that maps drives. If you find this failing when you move to Windows Vista (we have not seen that particular operation fail), you can postpone that part of the logon script until the user's desktop has been fully initialized. Microsoft provides a script, launchapp.wsf, on the TechNet Web site that creates a scheduled task instead. The actual logon script is started as soon as the launchapp script is done running, but this should be enough of a delay to make it work properly. Test whether you have the problem first though. Unless you have logon scripts with very specific traits, you will not have a problem.

Using Group Policy in a NAP Environment

We have deliberately not discussed Network Access Protection (NAP) much in this book. NAP is a policy enforcement mechanism, pieces of which ship in Windows Vista. NAP is designed to intercept and assess clients' configuration state before they receive full network connectivity. An administrator could define requirements that must be fulfilled before a client is permitted to access network resources, such as up-to-date patch state, and a firewall in a certain configuration.

The client component for NAP ships in Windows Vista, but as the server components are required, and will only ship in Windows Server Code Name Longhorn, we decided to skip most of our discussion of NAP until we write an as-yet-not-planned book on that product. Besides, NAP is a policy deployment and enforcement mechanism; not a security solution. NAP cannot keep malicious hosts out of the network. It can only ensure that hosts that want to comply with policy keep doing so.

There are some interesting things that happen to Group Policy when you use NAP, however, that merit mentioning here. The entire purpose of NAP is to deny clients full connectivity until they have proven themselves to be in a known good state. Until that time they are placed in "quarantine" where they have very limited access to network resources. NLA, which is used to detect the presence of a domain controller, unfortunately does not detect the transition from a quarantined to a non-quarantine environment. This means that NLA will detect the domain but the Group Policy client will be unable to download and apply Group Policy because the client is quarantined. When the client is released from quarantine, NLA fails to notice, and never notifies the Group Policy client to refresh group policy.

Microsoft has so far published only a fairly unsatisfactory work-around for this problem. It involves the administrator writing a script that continuously scours the Event Log for quarantine removal events, and triggers a Group Policy refresh when it sees one. One can only hope that Microsoft uses at least some of the developer hours between now and when Windows Server Code Name Longhorn finally ships to fix NLA to work with NAP.


Summary

Group Policy, as always, is a fascinating and somewhat scary topic. The changes in Windows Vista, with over 800 new settings, are not unusual in the history of Group Policy. It is a smart administrator that learns as much as she can about Group Policy and how to leverage it to gain better control and less administrative overhead.

It is encouraging to see that so many new security settings made it into Group Policy in Windows Vista. Obviously, much of what is in there will have no impact on security of most environments, but occasionally there is a nugget that truly makes a difference.

You can also leverage Group Policy in other ways. For example, if a vulnerability is made public that affects a particular component, you can probably disable that component temporarily using Group Policy, or you can configure the firewall to block the exploit. The tools are all there. The sky really is the limit in how you make use of them.


Best Practices

  • Build a small test bed, or two, where you can test various things relating to Group Policy. We very much like having a complete domain running in VMWare, Virtual PC, or a similar virtualization environment. It is an invaluable tool to tinker and learn with.

  • Download and peruse the settings reference for Group Policy in Windows Vista. Dig further into anything that triggers an interest and try it in your environment.

  • Get some references specific to Group Policy. Jeremy Moskowitz's book on Group Policy, or better yet, one of his seminars, are excellent choices. Jeremy has forgotten more about Group Policy than many of us will ever know. More information is available at http://www.GPanswers.com.

  • Give your administrators computers with Windows Vista now, if you have not already.

  • Start building GPOs specific to Windows Vista.

  • Do not mix settings for Windows XP and Windows Vista computers in the same GPOs.

  • Apply security settings sparingly. Stability is inversely proportional to the number of security tweaks you make, whereas actual security is rarely linearly proportional with those same tweaks.


Chapter 15: Thinking about Security

Does Windows Vista change something fundamental about information security? This book has 14 chapters covering all things new in Windows Vista. It discusses all the things that make propeller hats spin. Yet these are just new features. Fundamentally, Windows Vista has not changed the information security landscape. The features change how we manage things, and to some extent, what we manage. But information security is far more than that. It is driven by external factors. One of the things that makes information security so fascinating, and so maddeningly frustrating, is that those of us on the good side are not entirely in control. The mark of good security is the ability to predict and preempt, not just respond. In security, regardless of whether it is information security, computer security, or airport security, those who can only respond are continuously dragged around by the nose by the bad guys. Those who can predict and preempt can change the playing field. To do that, we need to develop a discipline that is strategically sound, temporally stable, and flexible. Windows Vista may give us the flexibility, but without the remainder of the discipline, without the strategy, we will be unable to get ahead of the bad guys. That is why we still need to consider traditional defenses and adapt them tactically using our new tools. The previous 14 chapters were about the new tools. This one is about the strategy.

It Still Comes Down to Risk Management

Above all, security always comes down to risk management. All too often, risk management is phrased in terms of "defense in depth" where "defense in depth" is generally held to mean "stuff we can't justify any other way." This is absolutely the wrong way to go about security. In Chapter 14, we discussed the "more settings must be better" syndrome. The mentality that if you just change more stuff you must have better security is anathema to risk management.

Risk management is much more complicated, and valuable, than merely making seemingly random tweaks. First, you must analyze your tolerance to risk. How risk averse are you and/or the organization you are securing? Everyone has an inherent propensity for risk, but it is moderated by circumstances. Next you must have an understanding of what you have to lose. What is the value at stake? Those are both easy-or at least, easier. Microsoft, Symantec, and Ziff-Davis produced a free assessment tool to help you understand those issues. The tool is available at https://www.securityguidance.com/.

The much harder item is to determine how likely you are to be attacked, and by which methods. The likelihood is typically related to how valuable you are to someone else. Put yourself in the attacker's mind for a minute. What would they do with your data? With your computer? With your network capacity? If you were out of business? How much are your assets worth to someone else?

Jesper's Position

If you are interested in securing your home computer, then chances are, much of what you have is not worth enough for a bad guy to target you specifically. Most attackers find it too tedious to attack home machines one-by-one to mine data. It takes too long unless you can automate it. That changes the attack method, and changes how you protect it. Many of the attacks are standardized, the malware more common. Generally, the payoff is not large enough to spend significant time crafting a specific exploit for a specific target.

Roger's Position

Ninety-nine percent of malware is designed to steal money, using stolen identities and passwords-which the malware programs do easily from home machines by installing monitoring programs and so on. Although businesses are more valuable to the bad guys, home computers are attacked as much, if not more, because they are typically easier to break into. Taken together, the value to the attacker of a few thousand random home computers is significant.

Enterprise Risk Management

For large enterprises, the scenario is much richer, as is the potential payoff. The volume of information that can be had is much greater. Consequently, the risk is typically higher. Unfortunately, many organizations tend to follow one of two approaches: ignore the vast majority of the problem, or come down so hard on it that the only way employees can be productive is by circumventing the policies in some way. Sometimes we even see a hybrid, where many significant problems are ignored, and the rest are dealt with in such a heavy-handed manner that the cure is worse than the disease.

One reason for this is an inadequate accounting for risk. The wisdom in infosec has for many years been that the risk equation is structured like Equation 15-1. The value P in Equation 15-1 is the probability of an event.

Image from book

ALE stands for "annualized loss expectancy" and is the estimated value of the loss in a given year. This equation has been used to quantify risk for many years. There is one problem with it, however. It fails to account for the impact of the proposed mitigation. The assumption is that the user is interested in discovering how much she should be willing to spend on mitigations. A mitigation that costs more to implement than the risk is worth is not worthwhile. That, however, fails to take into account the fact that it is not just the mitigation itself that has a cost. The mitigation often comes with side-effects, and those have a cost associated with them as well. A more complete risk equation is shown in Equation 15-2.

Image from book

Equation 15-2 modifies the ALE to take into account the changed probability and cost of loss after a mitigation, and the cost of the mitigation. The cost of the mitigation consists of the cost of the mitigation itself, and any expected cost of side-effects of the mitigation. By using an equation that takes into account the expected cost of mitigations we have a much more complete picture of the impact of our decisions. Equation 15-2 has the potential to more accurately account for the value of the risk. It reflects the fact that the mitigations and side-effects of mitigations are potentially costly. For instance, let us consider the case of wireless networking. Wireless networking has a risk of loss associated with it, as an attacker can potentially use it to break into the organization. Just to make numbers up, we will assume the probability of that event is 0.01 percent per year. The value of the loss that would occur in that case is harder to quantify, but let us say we are protecting personal data for 10,000 customers. The average cost of loss of such a record is $182 (according to the Ponemon Institute in 2007). In other words, the total possible loss is $1,820,000. That is how much we should be willing to spend, according to the conventional risk equation. According to the modified one, our willingness to spend would be offset by the impact of the mitigation.

One possible mitigation would be to put a virtual private network (VPN) device between the wireless network and the wired network. However, host-to-site VPN connections typically drop when there is an interruption in the underlying network. This can happen for a number of reasons, but a very common interruption in wireless networking is that users move from one access point to another as they move through the building. In fact, they could move from one access point to another without even moving the computer. This causes a disruption as the user needs to (a) recognize that a disconnection has occurred, (b) interrupt what she is doing to launch a VPN client to reconnect, and (c) re-establish the context for the task that was interrupted. This process can easily take five minutes each time, and it can happen several times a day.

For the sake of argument, let us say the disconnection event happens on average three times per day per user, including the initial setup. That is 15 minutes of lost productivity per user. There could also be data loss associated with this connectivity drop, but we will ignore that for now. There are approximately 200 workdays in a year, so each year every user loses 3,000 minutes, or 50 hours of work due to network connectivity issues. If you have 1,000 users, it means that every year you lose 50,000 hours of work. To estimate total cost, you would need to count how much each user costs per hour. A figure of $75–100 per hour is typical, after accounting for salary, benefits, and ancillary costs. Using the lower of those numbers, the potential cost of side-effects from our mitigation, a VPN device between our wireless and wired network, is $3,750,000. We do not have complete confidence in these figures, but we could say that it is about a 50/50 chance that things will play out this way. That means our estimated cost of the side-effects of the mitigation is $1,875,000. In other words, the cost of side effects from our mitigation is estimated at $55,000 per year more than the risk itself is worth! We do not even need to include the cost of actually building the mitigation. This mitigation option should be eliminated from consideration.

These are just made up figures, obviously, but the concept is critical. Much of what we today think of as the basic tenets of information security came from a military environment, where the cost of a breach could mean massive casualties. This led, naturally, to an extremely conservative approach. In a commercial or non-military public sector environment, and even in a military one, these models need to be reviewed and reconsidered based on a more risk-tolerant approach. Unfortunately, far too often, the security department views its job as removing all risk, and hence all work. They become the work stoppage department, and quickly become irrelevant and left out of all important decisions.

Taking this approach to security leads to a loss of benefits from security as the sensible consideration of risks, which the security department ostensibly is better at than anyone else, is removed from the decision making process. Security becomes irrelevant. Only by taking into account business needs, user desires, and what pain will be caused by our mitigations, can we become relevant again. In essence, the field of information security needs to question our world view. In short, we need to think differently about security and managing risk. We need to partner with the rest of the business and leverage others to improve our overall risk posture. The rest of this chapter looks at a number of areas of information security, and how Windows Vista can be leveraged to do just that.


The Three-Step Approach to Security

As we discussed earlier, security is too often treated as black or white. It is considered to be either on or off. The security group, if asked at all, all too often defaults to say no to just about everything the business tries to do. Consequently, the security group has become irrelevant.

Instead, consider what "defense in depth" really means. It really should mean that there are complementary security measures, not necessarily redundant ones. One of the authors once was brought in to evaluate a network design. When he asked what the ingress points to the data center looked like he was informed that there were two firewalls, something we usually refer to as a "dual-screened subnet." Normally that means there is a firewall in front of the data center (facing the Internet)-and another firewall behind the data center (facing the back-end or corporate network). It was not until later in the review process that he was informed that what this particular design group considered a "dual-screened subnet" was a data center that was screened by two firewalls, one right behind the other, in the front of the data center. When he probed for more information on how these firewalls were configured, he was informed that they were from two different manufacturers, but that the configuration on them was exactly the same, by design. In fact, the configuration file formats were essentially equivalent, so the operators would just copy one file to both firewalls. The back-end of the data center, meanwhile, was essentially wide open to the corporate network. This was considered to be defense-in-depth because if one firewall had a vulnerability, the other, one hopes, would not. In reality, the organization had spent a lot of effort on implementing tools that were not substantially contributing to security, in the process ignoring real problems. They were unable to even produce the likelihood that one or the other of the firewalls would have a vulnerability or anything else that quantified the value of having two firewalls. Meanwhile, the risk of leaving a data-center wide open to a corporate network should be relatively clear.

A complementary approach to security in this situation would have been to have a port filtering firewall in front, and then an application filtering firewall behind that. Those two would complement each other and provide redundant functionality. In the event that the front firewall had a problem that was so bad that it did not fail securely, the rear firewall would still be capable of catching it, even though its main job was more granular filtering. This type of design is the first of our three-step approach to security.

Keep 'em Off the Box

In the best of all worlds, the attack never gets to the box, the computer, in the first place. Something stops it from even getting there. One of the main ways to do that on a client OS, such as Windows Vista, is to use the principles of domain and server isolation, as discussed in Chapter 12. If clients listen only to requests coming from a small set of hosts, uninvited attacks, such as the common worms and a vulnerability in some default service, could be exploited only from a very small number of places.

Another way to keep attacks off the box is to prevent things from installing. By leveraging the low-rights processes that User Account Control (UAC) enables, many fewer problems can arrive through inadvertent clicks in Internet Explorer (IE). Over time, more low-rights applications, such as instant messaging applications, e-mail clients, and so on can be expected. This limits the potential for delivery of attacks through some of the historically more vulnerable channels.

There is nothing, however, that will have a bigger impact on keeping bad things off the box than user education. In the end, a user who wants to will always ensure that the naked dancing pigs get on the box. Only by partnering with the users can we make headway here. We are already hearing rumblings about organizations that will disable UAC. You would lose the low-rights IE (LoRIE) that way. However, if you at least make users run as standard users, which is considerably easier to do in Windows Vista than in Windows XP, you retain the benefit of some of the plumbing that went into UAC.

Keep 'em from Running

If malicious code should happen to get on the system, the next layer of protection must be to stop it from running, or at least doing any damage. The traditional way to do this was to use antivirus programs. Today the term "anti-malware" is much more appropriate because it is not just about viruses any more. Those programs will detect known bad things and keep those from running. Windows Vista ships with a phishing filter in IE, as well as an anti-spyware technology. Adding an antivirus solution to that is generally considered a best practice.

Another potential contender for use in keeping malicious code from running is Software Restriction Policies (SRP). SRP is a technology that you can use to specify executables that can and cannot execute on a computer. It has been around since Windows XP, and in that time has proven notoriously difficult to manage. It also turns out that SRP evaluation happens in the user's context, meaning that malicious code could actually disable the evaluation. Nevertheless, SRP has been used successfully on servers, where it is considerably more predictable what needs to run and where malicious code would have fewer interfaces to modify the evaluation available.

Another way to keep code from running is to simply not permit users to run it. For instance, if auto-run is disabled on removable media, users inserting that shiny USB flash drive they found in the parking lot, the one that was dropped there by attackers under contract by your worst competitor, will not auto-run a simple exploit when it is inserted into a USB port on the computer. Keep in mind, however, that USB devices, and Bluetooth devices, and many other things as well, cannot only change their device type ID, making the computer think they are something different; they also are Direct Memory access (DMA) devices. This means that they have direct access to system memory and can read and write to any memory segment on the computer, without auto-running a thing. If you really want to keep exploits from running on removable media, you need to keep them off the box in the first place. Device Control, which we discussed in Chapter 14, can achieve that, but the far easier, and more foolproof, method is to apply the contents of a tube of epoxy to every orifice you find on the back, front, sides, top, and bottom of the computer. Your risk posture will guide whether this is the acceptable way to mitigate this particular problem.

Keep 'em from Communicating

If you can't keep 'em from getting on the box, and you can't keep 'em from running, maybe you can at least keep 'em from communicating. This can turn a compromise of an entire network into a compromise of a single system. If a client manages to pick up some exploit, and the exploit spreads via the network, but none of the other clients will listen to the infected one, you have kept the bad code from communicating. If an exploit spreads via e-mail, but the mail server finds and blocks the attachment, you have kept the exploit from communicating.

The first inclination of security people is generally to put a host-based firewall on the computer and configure its outbound filtering. We discussed this in Chapter 11. Host-based outbound filtering is useful in a few isolated scenarios in Windows Vista, but primarily because of Service Hardening. However, you cannot keep a process that runs as an end user from communicating unless you are willing to keep the end user from communicating. You should configure outbound filters for processes that you can isolate, and push vendors you buy software from to do so automatically upon installation. That means the vendor has to write its software for least privilege, which is a new experience for many.

Thinking Differently about Security

We, the two authors of this book, usually agree on how to manage security, but sometimes we have slightly different views on how an organization should react to threats. In some cases, the difference stems from one of us being wrong (at least that is what the other one said). More often, we just have different ideas about what is sufficient, or we have a difference in approach, focus, and background. For the remainder of the chapter, we decided to each give our analysis of a common scenario. It may be that neither is right, and it may be that both are, but in different instances. In either case, we thought this dialectical approach to security would help you synthesize your own opinion, be it based on one or both of ours or something entirely different. The objective in the remaining pages is not necessarily to be correct, but rather to stimulate innovative thought. If you come away from this thinking more deeply and questioning conventional wisdom, our goal has been achieved.

The Top 2 (+ or −1, or so) Client Security Hacks

To start out, we decided to analyze our top client protection tools/technologies/processes. A few years ago, Microsoft launched the "Protect Your PC" marketing campaign, in response to an outcry resulting from the Blaster worm. That campaign carried the message of "patch, firewall, and anti-virus." All three of those are important, but does it still hold that those are the top three, or that they ever were?

Jesper's Thoughts

Assuming that you have already figured out patch management, if you start only two projects based on what we have covered in this book, it should be one that investigates how to protect clients from other clients, and one that helps you implement the principle of least privilege for your end users. Let us briefly talk about each.

We mentioned Server and Domain Isolation previously, and we spent a significant amount of time on it in Chapter 12. Implementing Server and Domain Isolation is largely a matter of determining permitted communications patterns in your network. Most of your project will be to map out what you think clients should do on the network, and on which networks. The permitted channels are almost certainly different on the corporate network and the wild Internet. We do, however, encourage you to consider what we said in Chapter 12, that the average organizational network today is semi-hostile at best. Do not design under the assumption that you are safe because you are on a shielded network. Design as if the network was hostile. Most likely, it is.

In Chapter 4, we discussed how much running as an administrator increases the potential for damage from user action. Windows Vista already limits that damage somewhat by making even administrators much less privileged by default. However, the protection offered by admin-approval mode is flawed for two reasons.

First, there almost certainly will be elevation of privilege attacks that permit an application running under admin approval mode, or even as a standard user, to escalate to a full admin. Obviously, this attack vector was considered during the implementation of the feature, but it is highly unlikely that all possible attacks were considered and closed, and in any case, logic would have it that we can never know for sure either way-until a successful attack is discovered.

Second, admin-approval mode works only if the user consistently makes intelligent security decisions. Think back to all the emergencies you have had to deal with throughout your career? What would you say the probability is that you can get all users to consistently make intelligent security decisions, all the time? We didn't think so. You can certainly improve the success rate with appropriate training, but unless you are extremely successful in removing security dependencies across systems, you will still have a situation in which one mistake by one user can have far-reaching consequences. Such mistakes are made much less likely if the users are not administrators of their systems.

Making users run as standard users requires a fair bit of forethought. What are the things they need to do that require admin privileges? Can you find out? Can you make those things not require admin privileges? Very often you can by judiciously loosening an Access Control List (ACL) on a certain binary, or a directory, or a registry key. Sometimes you can fix the problem by giving users an additional privilege or adding them to a group. For example, if roaming laptop users need to be able to release and renew their IP address leases you can grant them that ability by making them members of the Network Operators group.

Making users run as standard users also will require some planning to resolve issues that you would not otherwise have. When the VP of Marketing decides that it is absolutely critical to his job that he have iTunes on his laptop, how are you going to respond? You may be able to address that problem by making the program available as a package using Active Directory Software Installation or an Enterprise Management System (EMS). This will not always work. Apple, for example, does not currently permit redistribution of iTunes, even inside an organization using an EMS.

These two items-stopping client systems from listening to each other, and making users run as standard users-have the greatest potential benefit of any technology in Windows Vista. With other tools, such as tweaking Group Policy settings, modifying how IE acts, using anti-malware, and so on, you can stop specific attacks. Only least privilege and treating client computers as black holes, however, carry the potential to stop entire classes of attacks. Beyond these technologies, you are left with users as the primary line of defense.

Roger's Thoughts

The number one way to prevent current malicious attacks is not to be logged in with an Administrator account when it isn't needed. Because client-side attacks are so prevalent right now versus truly remote exploits, Vista's UAC will do a lot to stop current client-side attacks. But it's also my personal opinion that there is enough wriggle room in a standard user's permissions that malware writers will be able to code around UAC's protections. Some malware writers already do it. They make their malicious little creation write to HKey_Current_User instead of HKEY_Local_Machine. They can place their executable in \Windows\Temp or the Temporary Internet Files folders instead of System32. Windows doesn't care where it executes malware from. If the end user can be tricked into executing malicious executables (or data), it's always game over. Patching won't save you. Firewalls won't save you, and neither will antivirus programs.

Patching does have its benefits, but only if you patch everything-the OS and beyond. Many of today's administrators and users are lucky if they've got the major OS patches applied. According to many surveys, administrators and users don't do a good job of patching major common applications, such as Java, Macromedia Flash, and Adobe Acrobat. Right now, if I want to exploit somebody, all I would need to do is send a common, malformed data file with an embedded backdoor Trojan hidden inside.

Although firewalls help, they are almost a non-issue. Firewalls stop inbound attacks relatively well. But since most of today's maliciousness is the result of outbound client-side attacks, the rogue programs can easily bypass the filtering rules of the firewall. Nearly every network allows port 80 outbound. A smarter hacker will tell his program to piggyback on some approved process and go out on port 443 using heavy encryption. That way, the outgoing data stream is more than likely left alone and unmonitored. In fact, if a malicious outbound program doesn't use port 443, it is wasting valuable malicious computing cycles. Only a lazy hacker would choose a different port. Once the user has executed an untrusted executable, the host-based firewall can be bypassed, and it's game over-no matter what the firewall is and no matter where it is placed.

Antivirus programs are doing a horrible job of detecting previously unknown malware. I've been an antivirus consultant for 20 years now, and never have detection rates, across the board, been so bad. Blame it on polymorphic packers, blame it on sheer numbers, but an antivirus product today is more than likely not going to catch the malicious executable trying to launch on your PC.

So, all three of the major popular recommendations listed (patching, firewalls, and antivirus programs) really won't help improve your security in the long run. How do I know these three items aren't helping that much? Because most administrators and users are already doing those three things, and we haven't sent malware or malicious hackers packing yet. In fact, it's worse than ever.

If you want to protect your computer and your environment as best as you can, don't place your faith in a myriad of protection products and techniques. Spend your efforts on preventing users from executing and installing unauthorized executables. I don't care how you do it, just do it. Everything else you have to do in your security defense plan results because you don't want to do the one thing that will have the biggest, long-lasting impact on your overall security risk.

As Jesper mentioned, with Active Directory group policy and XP Pro (or later), you can use Software Restriction Policies. Group policy even has a very similar, slightly more limited, section for preventing programs from executing on Windows 2000 domain computers. Don't let your users be logged in as Administrators. Use appropriate NTFS permissions. Use third-party tools if you have to, but stop your users from executing and installing everything that they want. If you leave the security decision up to the end user, he or she will make the wrong decision. And that wrong decision compromises your network.

You might wonder whether my single recommendation is too Draconian. I get letters all the time to my weekly InfoWorld column telling me that if the reader were to implement such a software lockdown, their end users would revolt and that their company's business would come to a standstill. Hog wash!

Today, much of the Fortune 1000 already does this. They may have other names for it, such as "gold image," "base image," or something like that, but they do it. And it significantly reduces their risk of attack. The Fortune 1000 is somehow making record profits, despite the "Draconian" lockdown. It's much like a company-provided car. The company doesn't mind if you use it for occasional personal business, but they don't want you modifying it in such a way that it breaks all the time.

If I can spam your company with a malicious file attachment and get one of your employees to run it, leading to a complete network compromise in mere minutes, shouldn't you be doing something different? It's all right if you don't or can't implement software restriction policies. I've been at many companies where this is the case. It's just that everything else is second best and, in the long run, requires more work and effort.

Last, I'm a big believer in honeypots as early detection warning systems. No environment will be perfect. Mistakes happen, and malicious code eventually gets executed. Take a machine you're getting ready to throw away because it's too slow and make it a honeypot. Just place it in your network infrastructure somewhere where it's likely to get visited if a malicious insider or outsider starts exploring. Because it's a fake asset, nobody should every try to log into or port scan it. You will, of course, have to fine-tune the honeypot to filter out legitimate management pings and connections. But after that, if something touches it, have it send an alert to an incident response team. If you can't prevent an attack, the next best thing is early warning to reduce damage.

Anti-Malware Is Not a Panacea

Anti-malware software is seen as such an obvious need that few question it. But, is that right? Is it possible that anti-malware is not the panacea that many of the anti-malware vendors seem to claim it is?

Jesper's Thoughts

Anti-malware-long seen as the mainstay of client security-is able to contain exploits it is aware of. By its very nature, anti-malware technology is a reactive approach to security. Reactive approaches are very often important, but they cannot ever truly be a panacea unless they become proactive. For over 20 years, security has been about bar raising. The bad guys discover where our bar is set, and figure out a way to jump over it. We, or in the case of anti-malware, the vendors, respond with a new definition file, and the bar is raised. At some point, the bad guys jump over that bar, and so it is raised again. The cycle continues. How high can that bar be raised? Anti-malware vendors have talked for at least ten years about "behavior blocking" and "predictive analysis." They have even released products that claim to not just be an antivirus program, but an "Intrusion Prevention Technology" because those sound more advanced. The fact still remains that behavior blocking is about detecting known bad stuff. If the bad guy can figure out something that is bad, but not known, there is no protection.

Reliance on bar raising leads to an escalation of conflict. As one party, you, gets better at detecting known bad stuff, the other party, them, gets better at circumventing it. Given that there is an inherent time lag between when the exploit is produced and when the anti-malware vendor has an update available that blocks it, the attacker has a window of opportunity. Simply producing a new definitions file that can be used to detect the newest bad thing can take as long as three days. Add to that the lag in getting it deployed to all the clients that need it, and the window of opportunity can be a week or more. As long as the bad guy can make exploits that are different enough to circumvent the detection mechanism in a shorter amount of time, the detection mechanism will fail completely. If the exploit can mutate all on its own, there is no detection mechanism relying solely on knowing bad stuff that can protect against it.

A fundamentally more secure base, through the two methods I discussed earlier-host isolation and least privilege-allows the other technologies to be far more effective. By supplementing anti-malware, which, after all, can be quite useful, with other technologies that are more adaptive and/or more restrictive you can get true defense-in-depth: technologies complementing each other, instead of being redundant. By taking a minimalist approach and limiting the potential avenues for exploitation, you reduce your reliance on a single protection technology. Both least privilege and host isolation also permit you to tailor your security approach to the unique needs of your environment, whereas other technologies, notably anti-malware, are a one-size-fits-all approach that cannot be optimal in any environment.

That being said, there is no substitute for "wetware" (people). I personally have not had a virus get caught by an anti-virus scanner since 1991, and that one was on an Apple Macintosh II SE. Users who practice safe computing and do not engage in dangerous and promiscuous computing behavior are far less likely to have their computers infected with any malware. Most of the malware, after all, relies on social engineering to entice users to run them. If users were able to make better security decisions, it is possible that there might come a day when anti-malware is not needed. For that to happen, however, we need two things. First, we need software that helps people make good decisions. Let's repeat some earlier screenshots: How is a user to make an intelligent security decision based on the information given in Figures 15-1 and 15-2?

Image from book
Figure 15-1: How many users can make an intelligent security decision based on this dialog box?
Image from book
Figure 15-2: Or based on this one?

Software makers have always built security functionality on the assumption that users are stupid and cannot make decisions. This needs to change. Windows Vista provides us with an opportunity to start educating our users on how security affects them and how to react to many of the new dialog boxes they will see. However, nothing will truly change until software developers start figuring out how to give users better information, and that will not happen for as long as we buy their software without demanding that.

Roger's Thoughts

Although there are topics where Jesper and I disagree, this is one area where I couldn't agree more. I wouldn't change a sentence. The only thing I can add is that a far better goal than developers giving users better information to make decisions is to make the decision for them. Users shouldn't have to be security experts to run their PCs. They just want to run their legitimate applications, surf the Web, and maybe play a few games, read a few jokes, and watch some videos.

I believe developers should strive harder to make the appropriate decisions for users behind the scenes, so that the user never has an opportunity to make a decision. It's like anti-lock brakes on a car. Car manufacturers finally realized that too many drivers made the big mistake of completely stomping down on the brake pedal during a perceived collision, which removes direction control and actually lets the vehicle slide further than if the driver didn't push down all the way. Anti-lock brakes, when they sense the driver trying to depress the brake pedal too far down to fast, don't let the car tires completely stop moving. Instead, they apply micro stops and starts, which slows down the car as quickly as it is possible to do, while letting enough forward speed remain to give the driver control over their car.

An example of that in the computer world involves outbound blocking, host-based firewalls. Traditional host firewalls will prompt the user with messages similar to those shown previously in Figures 15-1 and 15-2. The more intelligent firewalls identify the requesting executable, look it up in their own internal database, and automatically make the decision for the user (when possible). Several host-based firewalls already have this feature, although it is often a premium option.

Tweaking It

The favorite tool of security people has always been the tweaks-the changes you make to a software product to make it "more secure." The assumption often is that the software can be tweaked to better suit your security needs, and that turns out to often be the case. Unfortunately, it is also often the case that the lists of tweaks, commonly peddled under the moniker of "Security Guides" do not take your security needs into account. As it were, many of them fail to take any security needs into account at all. They are just lists of tweaks. There are a few that are good. The Windows Server 2003 Security Guide is very good. The Windows Vista Security Guide is not quite as good, but still far better than many others. Which tweaks matter, however? Does Windows Vista really need many?

Security Tweaks You Should Make

In this section we each give a list of tweaks that we believe you should make to Windows Vista. You may be surprised to see how few there really are.

Jesper's List

My list for what tweaks to make is shorter than it has been for previous versions of Windows. The reason is that many of the changes are now enabled by default. Nevertheless, there is a short list of changes I make.

Password Strength

One of the most important things you can do is to change your password policy. It is well known that users, left to their own devices, use very weak passwords. Yet, it is not at all unknown how to improve the strength of a password. The best option is probably to not use passwords at all. Using smart cards or one-time password tokens provides far better security than passwords because it removes the fundamental weakness-human beings-from the solution. Nevertheless, many organizations cannot implement these technologies. For them, it is imperative to help (force?) users to use better passwords. The default minimum password length in Windows Vista is seven characters. If you increase that to nine you have protected yourself against virtually all password guessing attacks, as long as the passwords are not dictionary words. Only those attacks that use a dictionary with a near approximation of the actual password will have any chance of succeeding. Even if you go to only eight characters, you have stopped the vast majority of attacks.

Auditing

As with its predecessor, auditing is turned off in Windows Vista by default. Most environments should consider enabling at least some level of auditing. Doing so does not make sense unless you have a process to monitor the events, but you should have one as well. The Windows Vista Security Guide gives reasonable advice on auditing. Using the settings from the relevant configuration in it would be prudent.

Note that if you use the audit settings from the Windows Vista Security Guide you must also configure the "Audit: Force audit policy subcategory settings (Windows Vista Only) to override audit policy category settings." Otherwise the granular audit policies configured by the guide will not apply.

Remove Logon Privileges from Service Accounts

Service accounts are the accounts used as process identities for services. For instance, you may have an EMS or a security program that uses a domain account as its logon identity. These accounts should not be used interactively, and can be restricted from local logons by changing who has the "Allow logon locally" user right.

Network Security: LAN Manager Authentication Level

This is the infamous LMCompatibilityLevel setting. It is set to 3 by default on Windows Vista, which means the computer will send only NTLMv2 authentication outbound, but will accept inbound LM and NTLM authentication. Of course, the generation and storage of LM hashes is turned off by default, which means that the effective setting is actually 4-Send NTLMv2 response only, refuse LM. There is no LM hash to authenticate against. However, there is scant reason not to change this to 5, and refuse inbound NTLM as well. No currently supported version of Windows requires the use of NTLM. It will affect only inbound connections from Windows NT 4.0 systems, and other down-level systems. It could be considered good security hygiene not to permit inbound authentication from a 12-year-old, unsupported operating system.

Keep in mind in the context of NTLMv2 authentication, however, that setting LMCompatibilityLevel to 4 or 5 does nothing to remove LM and NTLM from the network. The client may still send them. I once was sent to discuss security with a large government customer who had been charged with removing LM and NTLM from his network. After a bit of discussion I discovered that he was responsible only for the servers and DCs, not the clients. I was forced to inform him that he would never be able to succeed in this goal because the clients send whatever they want. The goal of removing LM authentication from the network must rest with whoever controls the clients.

Server and Domain Isolation and Firewall Rules

As discussed, one of the most valuable things you can do to protect your network is to limit who can say what to whom. Every organization should review the default firewall settings and tweak them as necessary. For instance, outbound communications rules should be created for all services that are added to the system. Limiting communications is one of the highest bang-for-the-buck areas in security.

Full Hard Disk Encryption

There should be very little excuse for most organizations not to encrypt all hard drives, at least on all laptops-preferably on all computers. Windows Vista ships with the BitLocker feature to do this. However, it can be relatively expensive, at around $100 per seat, to upgrade from Business Edition, which does not have BitLocker, to Enterprise Edition, which does. Enterprise Edition is also not available to all customers, leaving many forced to get Ultimate Edition if they want BitLocker. For this reason, every organization should also evaluate third-party products, such as Utimaco Safeguard Easy, Mobile Armor Data Armor, and PGP. In the end, it is simply prudent practice these days for every organization to use full hard disk encryption everywhere. It provides a level of safeguarding against accidental data disclosure that is well worth the cost and overhead. In addition, I highly recommend that every mobile computer use full hard disk encryption with a second factor for authentication, one which must be kept separate from the computer itself.

Roger's List

I agree with Jesper's list. I'd like to add the following suggestions.

Strong Passwords-Go Long

When considering strong passwords, go longer, and focus less on complexity. Although adding additional character sets seems to mathematically make password cracking exponentially harder, the sad reality is that there is no way to enforce complexity. The vast majority of users, when told to make a complex password, make most of the same passwords or types of passwords. They choose a word root that can be found in a dictionary and add some complexity. If told to add a number, they add a 1 or 2, and it's located at the end. If told to uppercase a letter, it's at the beginning of the password, and more than likely is followed by a lowercase vowel. Forty to fifty percent of all passwords contain two of the three vowels o, a, or e. Password study after password study has shown this to be true.

So when given a chance to increase password strength, go long instead of increasing complexity. In the real world, a nine- or ten-character password is significantly stronger than a seven- or eight-character "complex" password.

Convert All Incoming E-mail to Plain Text

E-mail continues to be a major avenue for malicious attacks. Convert all inbound e-mail to plain-text by default. The user can convert back to HTML if they like, but in taking the less risky default, you will have significantly reduced the risk of attack. Conversion to plain-text removes embedded active content, reveals spoofed URLs, and removes malicious scripts.

Run Services on Non-Default Ports

Security by obscurity works. When running a popularly attacked service that runs on a known port, run it on another, non-default port if the general public doesn't need access to it. For example, if your environment runs Microsoft SQL servers, don't run them on ports 1433 or 1434. Instead, run them on something like 34133 and 34144. Why?

Because 99.99 percent of all remote attacks use automated malware that looks for the default ports only. By simply moving your services-be they SSH, RDP, SQL, or HTTP-to a high, non-default port, you significantly reduce your risk of attack. Yes, hackers can port scan your environment, but most don't. Of the ones that do, most run the default Nmap portscan, which scans only well-known ports. Running your services on a non-default, high port is one of the best security defenses you can have.

Don't Use Public, Shared Computers

I'm a freak about not using public, shared computers when using services that require you to input logon credential information. But at conferences and hotels, I often see people picking up their e-mail and logging on to their corporate network. Public computers are often compromised, especially at computer security conferences, and should never be trusted for anything more than picking up the latest headlines from the news Web sites.

Turn on DEP for Internet Explorer

As covered in Chapter 8, Internet Explorer's main executable, Iexplore.exe, is not protected by Date Execution Protection. Microsoft intentionally disabled it because a few popular add-ons and Sun's Java virtual machine could not execute if DEP was enabled. The popular add-ons have been updated. If you are not running Sun's JVM, enable DEP for Internet Explorer.

Security Tweaks You Shouldn't Make

There are a few tweaks that are just bad. First, there is the obvious that you should not disable default security settings. Then there is the danger of turning on a setting with severe side effects. This list is not exhaustive but includes some of the tweaks we have seen cause large problems in many organizations.

Jesper's List

My list of "don'ts" focuses on things that will destroy your computer, make it unsupportable, or make no difference. Several of these are a combination of the three. That's the beauty of bad tweaks: They are usually bad on so many levels.

Wholesale ACL Changes

I have seen many organizations completely destroy their network by making one simple change: modifying the default ACL on built-in objects in Windows. One favorite practice is to tweak the ACL on the root of the system drive. We discussed this problem in Chapter 5. The best advice is that while it is OK to change ACLs on individual binaries, it is extremely dangerous to change ACLs on entire directory hierarchies. This practice should be avoided at all costs. Few threats justify that type of modification to the OS.

Some organizations even use wholesale ACL changes to permit users to do things they could not otherwise do. For example, I have seen organizations change ACLs on %ProgramFiles% to permit standard users to run a particular program. This is highly unadvisable. A better approach would be to spend the effort determining which files and/or folders the program needs access to and loosen the ACL only on those. An even better approach is to return the program to the vendor that wrote it and demand either a program that works properly as a standard user or a full refund.

Many User Rights Changes

User rights and privileges are often extremely powerful. Many organizations will give users certain rights because some program or other requires it. Some of the privileges they assign to users effectively turn those users into administrators. Examples include the "Act as part of the operating system," "Debug programs," "Backup files or directories," "Load and unload device drivers," and "Modify an object label" privileges.

Disabling MSV1_0

Only once have I seem someone try something as absurd as attempting to disable MSV1_0. MSV1_0 is the authentication package that handles authentication to the local system, as well as passing authentication on to Kerberos for domain authentication. One organization I saw had apparently heard that MSV1_0 implemented NTLM, which is true, and that NTLM is bad, which is not quite true. From this, the IT Security personnel at the organization drew the absolutely absurd conclusion that it should disable MSV1_0 entirely, by removing its reference from the Registry as a logon package. This broke all local authentication. Domain authentication still worked. However, the organization also required resetting machine passwords every seven days. (Machine passwords are probably going to resist attacks for a few billion years.) In other words, if a computer was ever turned off for a couple of weeks the only fix was to re-image the system. Don't do that.

System Cryptography: Use FIPS-Compliant Algorithms for Encryption, Signing, and Hashing

FIPS refers to the U.S. Federal Information Processing Standard 140, the standard that defines which encryption algorithms are approved for use in Federal Government systems. Generally speaking, FIPS 140–1 (the old standard, which this setting enforces) advocates good algorithms, and using solid crypto is not bad. However, this particular setting is problematic because the Secure Sockets Layer (SSL) protocol used on virtually every secure Web site on the Internet is not FIPS 140-x compliant. In other words, if you enable this setting you disable use of secure Web sites. Not only that, but in current versions of Windows (Windows XP Pro SP2 and later), enabling FIPS will actually reduce the cryptographic strength of the ciphers used in many features in Windows (EFS, hashing, and so on). They already use FIPS 140–2 compliant ciphers.

Roger's List

People make a lot of tweaks, and some of these tweaks are fraught with peril. Some mistakes are naïve. Others are the result of over-enthusiastic experimentation. And some mistakes are clearly worse than others. While I could go on about these mistakes all day, two in particular are real pet peeves of mine.

Disabling UAC

Many Web sites and computer stores are recommending disabling UAC because it inconveniences the casual user too much. I've been using UAC for over a year now, and I can tell you that Microsoft has it pretty well fine-tuned. The average user, after a few weeks of use, will barely notice it. But when it pops up during installs and control panel activities, the user will be forced to make a single approval mouse click (if already logged in with an administrator account). It isn't much effort, it's almost not noticed, and it prevents a significant amount of current attacks.

During a recent Web-surfing session, I went looking for the Web Attacker Trojan. It is responsible for two-thirds of the client-side exploits that happen from a user visiting a compromised web page with an unpatched browser. Although I was intentionally looking for it, I was surprised when Vista popped up a UAC prompt when I visited a compromised Web site. No warning-just an admin approval prompt. I, of course, declined. Later, I visited the same Web site on my Windows XP Pro machine, fully patched. The Web Attacker Trojan silently installed on the older machine without even a blip or flash. UAC will stop many "drive-by-downloads" and for that reason, it should not be disabled.

Disabling Process Tracking Auditing

Many guides recommend disabling (or choosing No Auditing) for the Process Tracking audit policy category. Conventional wisdom says that the category causes too much unneeded "noise" as compared to things you need to be legitimately worried about. And this is true for most computer types, such as workstations and file servers.

But on dedicated domain controllers, it should be enabled. With it enabled, if a hacker is ever able to break into the domain controller, Process Tracking will log the programs they started, stopped, and stalled. Once a dedicated domain controller is up and functioning, it doesn't stop and start a lot of processes and programs. Administrators and end users shouldn't be starting Microsoft Office and web surfing from their domain controllers. On a dedicated domain controller, auditing Process Tracking is high value and low noise.

Agreeing to Disagree

How to best secure a computer, or a network of computers, is not a black and white issue. Each security professional will develop a slightly different approach based on his or her understanding of the situation, the threats, the needs of the organization, and the technology. Those who present the situation as a simple case of "if you don't do all these things you are not doing the right thing" are not only over-simplifying the problem-they are demonstrating a fundamental lack of understanding of how security works. The authors of the book do not always agree on how to manage security either. As we were discussing our approach to one particular issue for the book, we realized that not only were we not going to agree, but that the various arguments would be extremely valuable for the book as an example of how to analyze a situation and come up with individual solutions that handled the problem according to our individual needs (or prejudices). For that reason, we will present a rather more detailed analysis of one particular setting: account lockout.

There is, and has been for many years, a raging debate about the wisdom of account lockout. Account lockout is the feature that disables accounts when an attacker, or the legitimate user, guesses the password wrong more than a certain number of times. Account lockout is meant to provide some protection against attacks on weak passwords.

Account lockout has a number of parameters associated with it, as shown in Figure 15-3.

  • Account lockout duration: The time to keep the account locked out in minutes. If this is set to 0, the account remains locked out until an administrator unlocks it.

  • Account lockout threshold: The number of invalid logon attempts before the account is locked out. For instance, if this is set to 3, the account is locked out after the password has been entered incorrectly three times

  • Reset account lockout counter after: This parameter can control the counter that keeps track of invalid passwords. For instance, it is generally considered prudent to lock out the account only if the password is entered incorrectly n times within a span of a certain number of minutes. If this setting is configured at 30 minutes, the invalid logon attempt counter is reset to 0 after 30 minutes.

Image from book
Figure 15-3: Account Lockout settings

The facts surrounding account lockout are as follows:

  • Fact: No single factor has as large an impact on password strength as length.

  • Fact: The more characters in the character set the password was composed from, the stronger the password.

  • Fact: Passwords that can be attacked with heuristics are much weaker than passwords that cannot. However, even if heuristics are possible, length is still the all-important factor. If you have a passphrase composed of 5 words, chosen at random from a dictionary of 2,500 words, we know everything there is to know about the password. Yet, there are 2,500⁁5= 97,656,250,000,000,000 possible passwords, far exceeding the security requirements of all but a few organizations. If you know, however, that the first two words both start with E, and that there are only 200 words in the dictionary that start with E, you have (2,500⁁3)*(200⁁2)= 625,000,000,000,000 possibilities. That passphrase has a strength of 0.6 percent of the original. Now, if you offset that with another word, making the total length 6 words, you are back to a strength of 1.5625*10⁁18, which is 16 times stronger than the original. Adding just one word in length makes the password 16 times stronger, even after one accounts for the fact that it can be attacked with heuristics.

  • Fact: Account lockout works only on the authentication server, the computer that hosts the account. In a domain, this is a domain controller. Therefore, account lockout does not operate on domain accounts while the computer is not connected to the domain.

  • Fact: For several versions now Windows has included a delay feature that makes password guessing at the interactive logon prompt infeasible. If the password is entered incorrectly more than five times, each successive attempt takes 1 minute. In other words, the attacker can guess only one password per minute maximum at the interactive logon prompt.

  • Fact: Enabling account lockout creates a denial of service attack threat against the computer/network. The attacker can disable all operations on the network by repeatedly guessing known bad passwords against one or more accounts. This attack can, and has in the past, been used to lock out all accounts on the network, disabling all work until the attack stops.

  • Fact: Account lockout operates either for all or no accounts on the logon server. There is no way to exempt particular accounts. That means that services can also be disabled by locking out the accounts associated with them. However, administrative accounts on the logon server-in the case of a DC, domain administrative accounts-can always log on to the logon server interactively regardless of their lockout state. This is to ensure that someone can unlock the accounts.

Jesper's Position

As mentioned earlier, the purpose of account lockout is to protect weak passwords from being guessed. Therefore, it stands to reason that you can add one fact to the preceding material:

Tip

Additional fact: If passwords are not weak, they won't be guessed, and therefore do not require protection from that particular attack.

The decision as to whether to use account lockout, and what to set it to, can therefore be reduced to an assessment of how many accounts will be protected by it. In fact, you can extend this statement to say that account lockout provides no additional protection that you cannot get simply by having better passwords. Of course, that leaves you with two issues: what is a "better password" or more simply, what is a strong password; and how do you get users to use them? We cannot really answer the latter question before we answer the first, so let us address that one.

The mathematics of password strength is quite fascinating. The only truly meaningful measure of password strength is the length of time until the password will be successfully attacked, and that measure is based entirely on just a few factors:

  • The length of the password

  • The character set used for each character in the password

  • Whether heuristics can be used to attack the password

Image from book
IS PASSWORD THE RIGHT UNIT OF MEASURE?

In this discussion I refer to "password" and "character" somewhat loosely. As the astute reader will know, a "password" is actually a shared secret, shared between the subject and the object the subject is attempting to access. Not only does it not have to be a word at all, it could actually be a sequence of words, or something that looks like words. For instance, "I sent my dog to fetch the paper." is a perfectly legitimate password on many systems, including Windows. In this case, however, the "character" is probably not the most efficient way to attack this password. Rather, an attacker would probably have better luck permuting words, not characters. Thus, the "character set" is really a "word set" not a character set if you use a pass phrase, instead of a password. To simplify the discussion, however, and to demonstrate the mathematics more easily, I will keep referring to password and character in their traditional sense.

Image from book

The first two of the three factors that contribute to password strength combine to make all calculations exponential. For example, if a password has 8 characters, all randomly chosen from a character set of 62 characters, there would be 62⁁8= 218,340,105,584,896 possible passwords. The basic assumption of randomness is, of course, frequently violated, and this is often stated as one of the many reasons why passwords are a bad way to authenticate. However, one must realize that true randomness in passwords is not particularly important. What is important is seeming randomness. The password does not have to truly be random; it must just seem random from the point of view of an attacker. In other words, the attacker must not be able to use heuristics to attack the password. This assumption is also often violated, but it is a much lower bar than true randomness.

The exponential effect where the strength of a password is increased by a factor equivalent to the size of the character set for each character added to the password is crucial. It gives passwords several interesting mathematical properties:

  • No single factor is more important in password strength than length. For instance, in the 8-character password discussed previously, let us say you add 14 characters to the character set by including symbols in the password. This would give you 1,113,034,787,454,976 possible passwords, or four times as many possible passwords. That sounds great, but what if you instead added a single character in length, going to 9 characters? That would give you 13,537,086,546,263,552 possible passwords instead, or 62 times as many! Clearly, nothing contributes more to password strength than length.

  • There is very little difference in structure between an extremely weak, and an extremely strong password. For instance, a 6-character password, composed of a character set consisting of the 32 most common characters, will be guessed in roughly 10 days (using a brute force method and assuming no account lockout). Adding one character from the same set making the password 7 characters means it will be resilient for about a year. Adding another, making the password 8 characters, makes it resilient for 29 years. Go to 9 characters, and the password will last almost a millennium, and with 10 characters it will be resilient for almost 30,000 years, roughly as long as Homo Sapiens has walked the earth. (Note that none of these calculations take Moore's Law into account. Moores law says that computing horsepower will double roughly every 18 months. Historically, the industry has outperformed that prediction most of the time.)

Account lockout will be beneficial only for a certain category of passwords, and for a certain category of organizations. The passwords that benefit are those that without account lockout could be cracked within the validity period of the password, but which, with account lockout, will resist guessing attacks for as long as they are valid. For example, a password that takes a year to guess does not need account lockout protection if it is only valid for 90 days. A password that takes 30 seconds to guess without account lockout and 2 days with account lockout receives no benefit if it is valid for 90 days. However, a password that takes 2 days to guess without account lockout, and 120 days with, is protected by account lockout. The question is: what does such a password look like?

By analyzing the parameters of password strength, we can actually tell what such a password looks like. Table 15-1 shows an analysis, character by character, of how strong a password is. The data in this table assumes that an attacker can guess 600 passwords per second without account lockout. The account lockout figures use a lockout counter of 3 and a timer of one minute, resulting in only two guesses per minute. Strengths of passwords length one to eight characters are calculated based on heuristics from real passwords. Research has told us that passwords often have a capital letter in the first character (26 possibilities), a lower-case letter, typically an a, e, or o, in the second position, and then a mix of lowercase and uppercase, and finally either a 1 or a 2 in the last position (eighth in our case). Using these figures, you can tell that account lockout would protect five- and six-character passwords but that any password longer than seven characters would be strong enough without account lockout.

Table 15-1: Strength of Passwords with Various Parameters Open table as spreadsheet
CHAR POS | CHAR SET | POSSIBLE PASSWORDS | DAYS TO GUESS | DAYS TO GUESS WITH ACCOUNT LOCKOUT
2 | 3 | 78 | 0 | 0
3 | 52 | 4,056 | 0 | 0
4 | 52 | 210,912 | 0 | 24
5 | 52 | 10,967,424 | 0 | 1,269
6 | 52 | 570,306,048 | 6 | 66,008
7 | 52 | 29,655,914,496 | 286 | 3,432,398
8 | 2 | 59,311,828,992 | 572 | 6,864,795
9 | 32 | 1,897,978,527,744 | 18,306 | 219,673,441
10 | 32 | 60,735,312,887,808 | 585,796 | 7,029,550,103
11 | 32 | 1,943,530,012,409,860 | 18,745,467 | 224,945,603,288
12 | 32 | 62,192,960,397,115,400 | 599,854,942 | 7,198,259,305,222
13 | 32 | 1,990,174,732,707,690,000 | 19,195,358,147 | 230,344,297,767,094
14 | 32 | 63,685,591,446,646,200,000 | 614,251,460,712 | 7,371,017,528,547,010
15 | 32 | 2,037,938,926,292,680,000,000 | 19,656,046,742,792 | 235,872,560,913,504,000

The calculations in Table 15-1 are not particularly complicated and can be replicated for a number of scenarios. The results are relatively consistent: Account lockout can protect short passwords with small character sets. Increasing the password length by one or a few characters typically makes the password strong enough on its own to not need account lockout protection. Even if passwords were using only uppercase letters, an eight-character password would last 2,014 days. Account lockout would protect five-, six-, and seven-character passwords based on only uppercase letters.

Given the mathematics of passwords, and the analysis shown in Table 15-1, it is my firm belief that account lockout does not belong in the modern enterprise. Passwords should be at least eight characters long, which is easily enforceable via Group Policy. If analysis shows that users use extraordinarily weak passwords (i.e.. with an even smaller character set) length can be increased to nine or ten characters, which would protect the vast majority of passwords against guessing. Based on these figures, account lockout is not needed any longer.

In addition, an organization that has a very large number of accounts is unlikely to benefit from account lockout. If an attacker is interested only in an account out of hundreds of thousands, the attack can be modified to defeat account lockout. Instead of trying an entire dictionary against one account and then moving on to the next account the attacker would try one word against all accounts in turn. By the time he starts trying the second word against the first account the lockout timer has typically expired and he can try another word. Statistically it is equally likely to find one account in a large pool that has a particular password as it is to find on password from a large pool that maps to a certain account.

Account lockout may have been needed 25 years ago when passwords could be no longer than four characters and complexity was not supported. Today, it merely increases risk, by enabling an otherwise impossible attack. That risk, in my judgment, is unacceptably high for every environment, and greatly outweighs the extremely minor protection offered by the feature.

In addition, account lockout causes the organization to lose focus on the more important issue, which is improving password strength. It obscures the real problem: weak passwords, with a fix that does not actually solve that problem in the majority of cases. By simply enforcing slightly longer passwords and educating users on how to pick better passwords, the organization could make far more headway in security. Instead, organizations turn on account lockout, declare success and move on, leaving a gaping hole in their security. This is particularly true of organizations with a large number of users, as noted earlier.

Of course, if an organization absolutely cannot enforce better passwords, it should get rid of passwords altogether and use other means of authentication, such as smart cards or one-time PIN-type devices.

Roger's Position

Without programming your own password filter .DLL, or installing a third-party program, true password complexity cannot be guaranteed. In Windows today, passwords such as Password1, Password2, and P@ssw0rd, are considered complex. I can set my automated password-guessing tool to guess as many passwords as Windows will accept, fire it off against OWA or some other Internet-accessible interactive logon prompt, and let it guess for days to months. I can get around Windows' "auto-delay" feature by guessing in multiple sessions at the same time, using a varied list of names against multiple logon computers. The popular password-guessing program Hydra makes this all easily possible. Most "complex" passwords can be broken in a few days, when using well-known password logic (for example, the first letter is probably capitalized, a number is at the end and it is a 1 or a 2, the password contains two vowels, and so on). If passwords cannot be guaranteed to be complex on a Windows computer, then you need account lockout.

Enable account lockout with any setting. I personally like to tell Windows to lock out the account for 1 minute after three bad guesses in 1 minute, with the account auto-unlocking. This further delays any password guessing program, probably to the point of keeping it from being successful. But the best reason of all, over Jesper's recommendation, is that it generates an Account Locked Out event in the security log. While most administrators might ignore a "failed logon attempt message," which is relatively common, Account Locked Out messages are rarer, and easy to notice and monitor.

If an Internet worm or attacker tries to use the account lockout feature to denial service attack a network, clear up the program, stop the attack, and all users are let in 1 minute later automatically. If a malicious program or hacker is attacking my network, I'm not sure how comfortable I am letting my users log on during the active attack. Clear up the attack, and everyone is allowed back in 60 seconds later. Seems like a good tradeoff to me.


Wetware

Finally, the topic we would all prefer to avoid: wetware, the carbon-silicon interface. It is well "known" in the security community (and the IT community in general) that it would be much simpler to run networks if we did not have to support all those users. Unfortunately, not only do the users pay our salaries, they are the reason we have the networks in the first place. Security in particular and IT in general are rarely profit centers in and of themselves. We exist to provide a service.

The people we provide that service to, the end users, are by far the biggest security problem today. As we discussed earlier, the attackers are now shifting their focus to the easy target-people. Forgetting that ultimately your people hold your security in their hands would be fatal. We, as an industry, need to start questioning the practices put in place many years ago and determine how best to work with people to get their help in protecting our networks.

Probably the most serious security issue you will need to deal with for the foreseeable future will be social engineering. We are getting relatively good at securing technology. We are not nearly as good at securing people. As the technology gets better and more secure, the attackers will not be going away. They will be shifting their tactics to the soft underbelly-the end user. We have seen it for years in mass mailing worms. We are now seeing botnets established by exploiting vulnerabilities in PDF readers, picture parsers, and just plain programs that people click on. The field is turning in a direction where the attackers will do whatever it takes to get in, and that means they will often go after people.

If you do only one thing for security this year, start a security awareness program for your co-workers, your organization, your family, your friends, and even the guy who asked you a computer question at the supermarket. You will have done something to address this problem. No single vendor owns that problem, nor does it really make sense for them to. We need to address this as a society. We need to teach society what real security looks like and how to spot fraud and security theater.


Summary

Windows Vista may come with a number of new and interesting features. While you should definitely spend some time learning about them-and if you have gotten this far in the book you probably already have-they will not replace traditional, sensible risk management. There will always be a need for a reasoned approach to security, and as we improve the technology, we need to branch out and learn other areas of security, such as hardening people.


Best Practices

  • Figure out what your organization's risk management philosophy is. If there is none, start a project to develop one.

  • Question everything you know about security, including all we have said. Does it make sense given the threats you are facing? Does it make sense given the technology you have available?

  • Look at the tweaks in this book, in the Windows Vista Security Guide, and elsewhere, and analyze whether they can help you mitigate a realistic threat, without imposing undue burden on the organization.

  • Take a critical look at how to improve your security awareness program. If you do not have one, start one.


Appendix A: Building a Windows PE Boot Disk

With Windows Vista, Microsoft for the first time is making more widely available something called Windows Preinstallation Environment, or Windows PE (WinPE). WinPE is a minimal version of Windows designed to be booted from read-only media such as a CD. It was available to certain customers and OEMs previously, but with Windows Vista, Microsoft is making it freely downloadable.

WinPE is one of the most useful troubleshooting tools around, and every system administrator should have a copy sitting around for handling tasks that cannot be handled using the live, running operating system. New with WinPE 2.0, the version based on Windows Vista, is that you can also boot a computer from WinPE on a USB flash drive. To build that flash drive is a bit tricky, however. This appendix contains step-by-step instructions for how.

Building a WinPE Bootable USB Flash Drive

The first step in building a bootable WinPE Flash Drive is to download the Windows Automated Installation Kit (WAIK). It is available at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=.

You can also get WinPE from the Business Desktop Deployment Kit. As you may conclude from the distribution mechanisms, WinPE is actually designed primarily to be used for automated installations. In fact, when you boot a computer from the Windows Vista DVD media, you are actually booting into WinPE. The first set of screens is rendered in WinPE. If you are used to using WinPE based on Windows XP or Server 2003 you may immediately notice that those screens are graphical user interface (GUI) based, not command line interface (CLI). WinPE based on Windows XP and Server 2003 supported only CLI applications. Starting with the Windows Vista-based WinPE, many GUI applications are also supported under WinPE. This greatly expands the type of applications you can use to troubleshoot a system under WinPE.


Downloading WAIK

You will need to download either the 64-bit or 32-bit version of the WAIK, depending on which version of Windows you are running it on. You also need the WinPE.cab file, which contains the WinPE bits. Put it in the same directory as the WAIK installer. Once the files are downloaded, run the waik*.msi file for the platform you are using to install WAIK. If you are installing WAIK on Windows XP you will need to download and install MSXML 6.0 first. It is available at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=

There is also at least one security update for MSXML 6.0 already so be sure you pay a visit to Microsoft Update before you go surfing the Web on the computer you installed MSXML on.


Building the WinPE Image

After you have installed MSXML (if needed) and WAIK, take the following steps:

  1. Open a WinPE Tools command prompt by clicking Start:All Programs: Microsoft Windows AIK:Windows PE Tools Command Prompt.

  2. Copy the WinPE source files to a temporary directory by typing the following command in the PE Tools command prompt

    copype.cmd x86 c:\winPE_x86

    Note that if you want to build a 64-bit WinPE disk, you use x64 instead of x86 throughout. We will use x86 in the remainder of these instructions for simplicity.

  3. Next, you want to mount your image to a directory so you can customize it. You do that with the following command:

    imagex /mountrw c:\winpe_x86\winpe.wim 1 c:\winpe_x86\mount

    The mount directory is essentially a link to what is in the WIM file that allows you to read and write its contents. You use that to add additional tools and packages to the image.

  4. Add features. WinPE comes with a number of features that are not installed by default to save space. This includes language packs and additional features. If you have enough space, say half a gigabyte, it is worth it to install all of them. Table A-1 lists the packages that are included with WinPE.

    Table A-1: Packages Included with WinPE
    Open table as spreadsheet

    PACKAGE NAME

    PACKAGE CONTENTS

    WinPE-HTA-Package

    HTML application support

    WinPE-MDAC-Package

    Microsoft Data Access Component support

    WinPE-Scripting-Package

    Windows Script Host support

    WinPE-XML-Package

    Microsoft XML (MSXML) parser support

    WinPE-WMI-Package

    Windows Management Instrumentation support

    WinPE-FontSupport-JA-JP-Package

    Japanese font support

    WinPE-FontSupport-KO-KR-Package

    Korean font support

    WinPE-FontSupport-ZH-CN-Package

    Chinese simplified (People's Republic of China) font support

    WinPE-FontSupport-ZH-HK-Package

    Chinese traditional, Hong Kong SAR font support

    WinPE-FontSupport-ZH-TW-Package

    Chinese traditional, Republic of China font support

    To install the packages, run the following command once for each package:

    peimg /install=<package name> c:\winpe_x86\mount\Windows

You can install all the packages by using * instead of <package name>:

  5. If you need to install custom drivers this would be the time to do it. You can do that with the peimg command as well, using the /inf switch. You should do this, for example, if you want a network-ready WinPE image using a network card that does not have a driver in the standard image.

  6. You can add your own custom tools by copying them into the c:\winpe_x86\ISO directory. You may also want certain other tools, such as the imagex tool used to capture and apply installation images just as you did before, and the Package Manager tool that is used to service those images. Copy those latter two using these commands:

    copy "c:\Program Files\Windows AIK\Tools\x86\imagex.exe"   Image from book
c:\winPE_x86\ISO\servicing
xcopy "c:\Program Files\Windows AIK\Tools\x86\Servicing"   Image from book
c:\winpe_x86\iso\Servicing /s
copy %windir%\system32\msxml6*.dll c:\winpe_x86\iso\Servicing

    If you so desire, you can put the utilities in Step 6 in the mount directory instead of the iso directory. The iso directory is mounted using the first available drive letter when you boot into WinPE. If you put the tools in the mount directory instead, they will be loaded into the RAM disk that WinPE is loaded into and will be accessible using the X: drive under WinPE just like the tools included by default. This obviously increases the size of the image in memory, however. Because you are planning to run WinPE from a USB flash drive, the speed difference is so marginal, we see no need to increase the memory footprint further.

  7. Prepare your image. Preparing your image optimizes it and removes any options that you do not need. For example, in our test used to develop these instructions, the image was 1.1GB on disk before running the prep command:

    peimg /prep c:\winpe_x86\mount\Windows

    After running peimg /prep, the image size is down to 685MB.

  8. Commit your changes and finalize the image. You do that using this command:

    imagex /unmount c:\winpe_x86\mount /commit

    This makes your changes permanent and unmounts the image. If you do not do this you will lose all the changes you have made and you will leave a large number of files in the mount directory locked open so that you cannot delete them.

  9. Finalize your ISO directory by taking the changes you have made to the original image and copying them into the ISO directory where all your source files for your WinPE image now sit:

    copy c:\winpe_x86\winpe.wim c:\winpe_x86\ISO\sources\boot.wim

  10. You now have a complete WinPE image. You can do a number of things with it

    • Create an ISO image. Having an ISO image with WinPE is convenient because it is an easy way to distribute the image. You can also use it to boot virtual machines by mounting the ISO image as a CD. To create an ISO image, run this command:

      oscdimg -n -bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO   Image from book
c:\winpe_x86\winpe_x86.iso

As you are probably aware, to have a bootable ISO image you must have a boot sector. Fortunately, the boot sector comes with WinPE; it is the http://www.etfsboot.com file.

  • If you are of the old school and want a CD copy of your WinPE image you can burn the ISO image to CD with your favorite CD burning program.

  • Create a bootable WinPE image on a USB flash drive. This is by far the coolest way to use WinPE. You need a 256MB or larger flash drive to do this. The steps for how start in Step 11.

  11. Plug your USB flash drive into a computer running Windows Vista. It is very important that the computer run Windows Vista. Diskpart in Windows Server 2003 and earlier does not support manipulating USB flash drives.

  12. You need to prepare the USB flash drive using diskpart, the disk partitioning tool. Start that tool by typing diskpart at a command line. If you have not elevated the command prompt already, you will be asked to do so now.

  13. Partition and prepare your USB flash drive using these commands

    1. List disk: This lists the disks in your computer. You do this only to ensure that you know which one is your USB flash drive. Take care here. The next few steps will completely erase the drive! You do not want to do this with the wrong drive.

    2. Select disk <disk number>: Substitute the disk number shown for your USB flash drive in Step 13 a for <disk number>. Again, make sure you get this one right!

    3. Clean: This command zeros every sector on the disk. In other words, it is a completely destructive wipe so you need to be careful in Step 13 b.

    4. Create partition primary: This creates a primary (bootable) partition on the USB flash drive.

    5. Select partition 1: Selects your partition so you can manipulate it further.

    6. Active: Marks the partition as active (the partition holding the boot files).

    7. Format fs=fat32: Formats the partition using the Fat32 file system.

    8. Assign: Assigns a drive letter to your new partition in case it had not already been done. Usually it is already done.

    9. Exit: Quits diskpart. You now have a formatted, empty, bootable USB flash drive. Only the files you want to put on it are missing.

  14. Copy the files in the ISO folder to the USB flash drive. You can do this via Windows Explorer, or by using this command in the command prompt you already have open:

    xcopy c:\winpe_x86\iso\*.* /s /e <drive letter>\i
where <drive letter> is the drive letter assigned to your USB flash i
drive.

Congratulations! You now have a bootable Windows PE image. This is one of the most useful little tools you can have in your bag for troubleshooting or repairing Windows. You can also use it to flash BIOS files, prepare disks, and for a host of other tasks. We're sure you will think of things we had not imagined.


Appendix B: References

64-bit Anti-Virus Software, http://www.msinfluentials.com/blogs/jesper/archive/2007/02/17/64-bit-anti-virus-for-vista.aspx.

Biba, K. J. Integrity considerations for secure computer systems, Technical Report MTR-3153. (1975). Bedford, MA: Mitre Corporation.

Blaster worm information, http://www.en.wikipedia.org/wiki/Blaster_worm.

Bollefer, T., Chander, G., Johansson, J., Kass, M., & Olson, E. Building and Configuring More Secure Web Sites. (December, 2002). Retrieved February 20, 2007, from Microsoft Developer Network, http://www.msdn2.microsoft.com/enus/library/aa302370.aspx.

Bowditch, N. The American Practical Navigator. (1802). Paradise Cay Publications.

Bradley, S. (2006). Retrieved January 14, 2007, from ThreatCode: http://www.threatcode.com.

Brett Hill's IIS http://www.Answers.com, http://www.iisanswers.com.

Brown, K. (2006). Retrieved January 14, 2007, from Hall of Shame, http://www.pluralsite.com/wiki/default.aspx/Keith/HallOfShame.html.

The Cable Guy. AuthIP In Windows Vista. (August 1, 2006). Retrieved February 19, 2007, from Microsoft TechNet, http://www.microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Desktop Isolation Security Bulletin, http://www.microsoft.com/technet/security/bulletin/MS00-020.msp.

Flaming, R. UAC in MSI Notes. (September 20, 2006). Retrieved January 14, 2007, from Microsoft Developer Network, http://www.blogs.msdn.com/rflaming/archive/2006/09/20/763945.aspx.

Fry, J. D. D: Notebook. (2005) Retrieved January 14, 2007, from Wall Street Journal Online, http://www.online.wsj.com/public/article/SB111684809888140520-uxjBS77gsFQvsi4ikXZzNxZjpd8_20060523.html?mod=blogs.

Howard, M. Weblog. (2007). Retrieved January 14, 2007, from Microsoft Developer Network, http://www.blogs.msdn.com/michael_howard.

Johansson, J. M. Frequently Asked Questions About Passwords. (October 12, 2005). Retrieved January 25, 2007, from Microsoft TechNet, http://www.microsoft.com/technet/community/columns/secmgmt/sm1005.mspx.

Johansson, J. M. Help Wanted-Need "People People". (2006). TechNet Magazine, http://www.microsoft.com/technet/technetmag/issues/2006/07/SecurityWatch/default.aspx

Johansson, J. M. More options on protecting against recent IE vulnerabilities on a domain. (September 22, 2006). Retrieved February 14, 2007, from Jesper's Blog, http://www.msinfluentials.com/blogs/jesper/archive/2006/09/22/More-options-on-protecting-against-the-VML-vulnerability-on-a-domain.aspx.

Johansson, J. M. The Most Misunderstood Security Setting of All Time. (August, 2006). TechNet Magazine.

Johansson, J. M. Please Don't Disable Security Features, At Least While We Are Testing Them. (June 22, 2006). Retrieved January 14, 2007, from Microsoft TechNet, http://www.blogs.technet.com/jesper_johansson/archive/2006/06/22/438316.aspx.

Johansson, J. M. Protect Your Windows Network. (2005). New York: Addison-Wesley.

Mar-Elia, Darren, et. al, Microsoft Windows Group Policy Guide (Pro-One-Offs), Microsoft Press, 2005.

Margosis, A. Weblog. (2007). Retrieved January 14, 2007, from Microsoft Developer Network, http://www.blogs.msdn.com/aaron_margosis/default.aspx.

Maybeck, H. F. Z-Time. (2006). Retrieved January 14, 2007, http://www.maybeck.com/ztime/.

Microsoft Corporation. Active Directory Schema Extensions for Windows Vista Wireless and Wired Group Policy Enhancements. (May 31, 2006) Retrieved January 20, 2007, from Microsoft TechNet, http://www.microsoft.com/technet/network/wifi/vista_ad_ext.mspx.

Microsoft Corporation. ADMX Schema. (2007). Retrieved January 18, 2007, from Microsoft Developer Network, http://www.msdn2.microsoft.com/en-gb/library/aa373476.aspx.

Microsoft Corporation. Certain Programs Do Not Work Correctly If You Log On Using A Limited User Account. (2006). Retrieved January 14, 2007, from Microsoft TechNet, http://www.support.microsoft.com/default.aspx?scid=kb;enus;307091.

Microsoft Corporation. Configuring Active Directory to Back up Windows Bit-Locker Drive Encryption and Trusted Platform Module Recovery Information. (January 9, 2007). Retrieved January 20, 2007, from Microsoft Download Center, http://www.microsoft.com/downloads/details.aspx?FamilyID=.

Microsoft Corporation. The COM Elevation Moniker. (January 2007). Retrieved January 18, 2007, from Microsoft Developer Network, http://www.msdn2.microsoft.com/en-us/library/ms679687.aspx.

Microsoft Corporation. Deploying Group Policy Using Windows Vista. (2007). Retrieved January 18, 2007, from Microsoft TechNet, http://www.go.microsoft.com/fwlink/?LinkId=77080.

Microsoft Corporation. Domain Isolation with Microsoft Windows explained. (2007). Retrieved February 19, 2007, from Microsoft TechNet, http://www.technet2.microsoft.com/WindowsVista/en/library/1033.mspx.

Microsoft Corporation. Policy Series: Group Policy Security Templates and IPSEC. (2004). Retrieved February 19, 2007, from Microsoft TechNet, http://www.microsoft.com/technet/community/chats/trans/windowsnet/wnet_112904b.mspx.

Microsoft Corporation. Group Policy Settings Reference for Windows Vista. (November 20, 2006). Retrieved January 15, 2007, from http://www.Microsoft.com, http://www.go.microsoft.com/fwlink/?LinkId=54020.

Microsoft Corporation. Security Configuration Guidance Support. (February 6, 2007) Retrieved February 14, 2007, from Microsoft Knowledge Base, http://www.support.microsoft.com/kb/885409/en-us.

Microsoft Corporation. Security Descriptor Definition Language. (2007) Retrieved February 14, 2007, from Microsoft Developer Network, http://www.msdn2.microsoft.com/en-us/library/aa379567.aspx.

Microsoft Corporation. Services in Windows Vista. (2006). http://www.go.microsoft.com/fwlink/?LinkId=71280.

Microsoft Corporation. ShellExecuteEx Function. (2007). Retrieved January 18, 2007, from Microsoft Developer Network, http://www.msdn.microsoft.com/library/en-us/shellcc/platform/shell/reference/functions/shellexecuteex.asp.

Microsoft Corporation. Step-By-Step Guide to Controlling Device Installation and Usage with Group Policy. (2007). Retrieved January 18, 2007, from Microsoft TechNet, http://www.go.microsoft.com/fwlink/?LinkId=75123.

Microsoft Corporation. Step-by-Step Guide to Managing Multiple Local Group Policy Objects. (2007) Retrieved January 16, 2007, from Microsoft TechNet, http://www.go.microsoft.com/fwlink/?LinkId=73434.

Microsoft Corporation. System-Supplied Device Setup Classes. (2007). Retrieved January 18, 2007, from Microsoft Developer Network, http://www.msdn2.microsoft.com/en-us/library/ms791130.aspx.

Microsoft Corporation. Troubleshooting Group Policy Using Event Logs. (2007) Retrieved January 20, 2007, from Microsoft TechNet, http://www.go.microsoft.com/fwlink/?LinkId=74139.

Microsoft Corporation. When you use Windows Server 2003 or Windows XP to modify a Windows Vista registry hive, Windows Vista registry key flags are removed. (January 10, 2007) Retrieved January 20, 2007, from Microsoft TechNet, http://www.support.microsoft.com/?kbid=926044.

Microsoft Corporation. Windows Server 2003 Group Policy. (2006). Retrieved January 15, 2007, from Microsoft TechNet, http://www.go.microsoft.com/fwlink/?linkid=15088.

Microsoft Corporation. Windows Server 2003 Security Guide. (May 18, 2006). Retrieved March 16, 2007, from Microsoft Download Center, http://www.microsoft.com/downloads/details.aspx?familyid=.

Microsoft Corporation. Windows Vista Security Guide. (November 20, 2006) Retrieved January 15, 2007, from Microsoft TechNet, http://www.go.microsoft.com/fwlink/?LinkId=74028.

Microsoft Corporation. (2006). Retrieved January 14, 2007, from Microsoft Platform Software Development Kit, http://www.go.microsoft.com/fwlink?LinkID=55774.

Microsoft Desktop Optimization Pack, http://www.microsoft.com/windowsvista/getready/optimizeddesktop.mspx.

Microsoft's IIS Internet Information Services site, http://www.iis.net.

Microsoft SoftGrid, http://www.softricity.com/index.asp.

Moskowitz, J. Group Policy, Profiles, and IntelliMirror for WindowsVista, Windows2003, WindowsXP, and Windows2000, 4th Edition. (2007). Sybex.

Ponemon Institute. Ponemon Institute. (2007). Retrieved January 22, 2007, http://www.ponemon.org.

Russinovich, M. E. & Solomon, David A., Microsoft Windows Internals 4th Ed., (2004). Microsoft Press.

Server and Domain Isolation Tech Center, http://www.microsoft.com/sdisolation.

Shatter Attack, http://www.microsoft.com/technet/security/bulletin/MS02-071.msp.

SoftGrid Demo, http://www.blogs.technet.com/kevinsul_blog/archive/2006/09/06/454467.aspx.

SQL Slammer worm information, http://www.en.wikipedia.org/wiki/SQL_slammer_worm.

Threat Code, http://www.threatcode.com.

User Account Control Overview, http://www.microsoft.com/technet/technetmag/issues/2006/11/UAC/default.aspx.

Windows Resource Protection, http://www.msdn.microsoft.com/library/enus/dnlong/html/AppComp.asp?frame=true#appcomp_topic6.

Windows Vista Restart Manager, http://www.msdn.microsoft.com/library/en-us/rstmgr/rstmgr/portal.asp.

Writing Services for Compatibility with Windows Vista, http://www.microsoft.com/whdc/system/vista/services.mspx.


Index

A

access checks, 127
access control list entries (ACEs), 24, 174
components, 174
deny, 184-186
Documents and Settings with, 184-185
icalcls tool and find all, 195
SIDs and, 174
access control lists (ACLs), 114-117, 171-201. See also ACL UI; discretionary access control lists; mandatory access control lists; system access control lists
default, 183
significant changes in, 183
definition, 171
earlier versions, 178-179
editor, 177
forms of, 173
major changes in, 178-179
management, 171-201
best practices, 201
permissions, 24, 171
modification, 156
registry, 199-200
representations, 174
resetting, 195
icacls and, 195
restoring, 192-193
icacls and, 192-193
saving, 191, 192
editing and, 192
icacls tool and, 191, 192
subinacl tool and, 199, 201
terminology, 172-175
tools for managing, 190-199
using, 175-178
verification of, 177
Windows XP, 178-179
default, 179
problems in, 178-179
access control permissions, IIS, 326-332
"Access Credential Manager as a trusted caller," 141
Access data sources across domains (setting), 270, 279
access masks, 174
access points (APs), 462. See also Wi-Fi
access tokens, 114, 125. See also security tokens
account lockout, 47, 539-546
facts, 540-541
parameters/settings, 539-540
password strength and, 541-545
account rights, 140
privileges v., 140
accounts. See specific accounts
ACEs. See access control list entries
ACL editor, 177. See also access control lists
ACL UI, 177, 197-199. See also access control lists
changes to, 197-199
Windows XP, 197
ACLs. See access control lists
Active Directory, 112.
See also Security Accounts Manager
SAM v., 112
Schema, 514
Active Scripting (setting), 275, 281
ActiveX controls, 33, 222, 223, 257
ActiveX controls and plug-ins (settings), 265-268, 278-279. See also specific settings
summary of, 278-279
ActiveX Installer service, 136, 137, 218-220, 222
Adobe Flash Player and, 219
configuration, 218-220
documentation on, 219
usage, 219
Add-on management, 256-257
Address Space Layout Randomization (ASLR), 5
Ad-Hoc mode, 462-463
admin-approval mode, 133, 136, 168
consent prompt settings for, 150
administrative templates, 492-493
settings, 504
new, 504-510
reboot/logon required, 510
Administrator account, built-in, 146-147, 180
disabled by default, 180
security importance of, 528, 529
filtered token for, 150
setting, 150
RID 500, 124, 146, 180
in safe mode, 146, 147
special treatment of, 146-147, 180
Administrator Lists, 317
administrators (admins), 128
non-, 129
UAC and, 129-130
power of, 129
ADMX files, 39, 492-493, 514, 515
migration tool, 493
template embedding, 493
Adobe Flash Player, 219
ActiveX Installer and, 219
Advanced Group Policy Management toolkit, Microsoft, 222
advfirewall, 424
adware, 64-65
browser cookies, 237
AES. See Asymmetric Encryption Standard
Airsnort, 465
All Users profile, 91
Allow META REFRESH (setting), 270, 279
Allow previously unused ActiveX controls to run without prompting (setting), 265, 278
Allow programmatic clipboard access (setting), 275-276, 281
Allow scripting of Internet Explorer web browser control (setting), 270-271, 279
Allow script-initiated Windows without size or position constraints (setting), 271, 279
Allow scriptlets (setting), 266, 278
Allow status bar updates via script (setting), 276, 281
Allow web pages to use restricted protocols for active content (setting), 271, 280
Allow websites to open Windows without address or status bars (setting), 271, 280
Allow websites to prompt for information using scripted window (setting), 276, 281
Anonymous authentication, 320, 323
anti-hammering defense, 47
anti-malware. See malware, automated
anti-phishing filter. See phishing filter
anti-virus programs. See viruses
API. See Application Programming Interfaces
application(s)
malware location in, 66
manifests, 165
misconfiguration, 56-57
security, 203-223
best practices, 222-223
UAC leveraging in, 164-167
UIAccess and, 152
vulnerabilities, 54-56
web server, 294-295
application pools, 309-311
identities, 311-314
Application Programming Interfaces (API), 424
Windows Firewall, 424-425
APs. See access points
Aronoff, Andrew, 70
ASLR. See Address Space Layout Randomization
ASP.NET Impersonation, 320-321
other authentication methods v., 325
Asymmetric Encryption Standard (AES), 26, 466
at.exe, 216
Attachment Manager, 506
attachments, malicious. See malicious file attachments
attacks. See specific attacks
auditing, 162, 533
elevation, 162-164
Process Tracking, 538
security tweak, 533
Auditpol.exe, 30
authentication exemption rules, 428
authentication methods, 14-16, 109. See also logon authentication; specific authentication methods
IIS, 318-325
support for, 14-16
authentication protocols, 110-112. See also Kerberos; LAN Manager; NT LAN Manager
challenge-response, 111
Authenticode, 265
reliant components-Run signed/not signed with, 265, 278
AuthIP, 451-452
multiple credentials and, 451-452
SDI and, 451-452
automated malware. See malware, automated
Automatic prompting for ActiveX controls (setting), 266, 278
Automatic prompting for file downloads (setting), 268-269, 279
Automatic Updates, 230
autorun programs, 99-100
locations for, 99-100
Autoruns utility, 70, 100, 235
example, 100
Web site location, 100


Previous Page
Next Page

Index

B

back-end databases, 295
issues, 295
backup application, improvements to, 31
Backup, Windows, 31
Basic authentication, 322, 324
other authentication methods v., 325
BCD store. See Boot Configuration Data store
BCD00000000, 102
Bcdedit.exe, 9, 10
BCD.log, 9
beacon packets, 462
Biba model, 146, 158
binaries
signed, 134
Microsoft, 134
un-signed, 134, 135
Binary and script behaviors (setting), 266, 278
binary behaviors, 266
biometrics, support for, 14, 15, 16
BitLocker Drive Encryption, 11-12, 76-79, 534, 535. See also Trusted Platform Module
applet, 83
enabling steps for TPM and, 80-87
Group Policy settings, 82, 83, 514
recovery key, 84
saving, 84, 85
storage options, 84, 85
startup options, 84
system check, 86
BitLocker Drive Preparation Tool, 78
black screen, 133, 158
Blaster worm, 448, 508, 526
blue screens, 19
device drivers and, 19
Bluetooth, 461
boot code, Vista, 74, 75
Boot Configuration Data (BCD) store, 8-10, 74, 75
boot files, new, 9
Boot Loader, Vista, 75, 76
Boot Manager
EFI, 74, 75
Windows, 9, 74, 75, 76
boot sequence
improvements, 8-12
process, 74-76
summary, 75
boot time filtering, Windows Firewall and, 409-410
boot viruses, 76
Bootmgr, 9, 74, 75, 76
Bootmgr.efi, 74, 75
Boot-up key, 79
options, 79
bot(s), 63, 64, 226
phoning home, 64
botnets, 63, 546
Bradley, Susan, 128
Brown, Keith, 128
browser(s). See also Internet Explorer 7.0; specific browsers
IE v. other, 245-247
browser cookies, unwanted, 237. See also Windows Defender
Browsing (settings)
Disable script debugging (Internet Explorer or other), 282, 287
Display a notification about every script error, 282, 287
Enable third-party browser extensions, 282, 287
Use inline AutoComplete, 282, 287
brute force attacks, 46
buffer overflows, 51-54
attack programs, 52
defense against, 54, 92
e-mails and, 384
exploitation, 51-54
web server software, 296
built-in Administrator account. See Administrator account, built-in
built-in groups. See groups, built-in
built-in users. See users, built-in
Bypass Traverse Checking, 186


Previous Page
Next Page

Index

C

C++ security, 4-5
CA. See Collision Avoidance
cached credentials, 113-114
cacls.exe tool, 191. See also icaclsexe command-line tool
replacement of, 191
updates, 191
Cain & Abel program, 48, 49, 57
network sniffing with, 50, 51
cards, 33
CardSpace, 33-34, 259-260
Web discussion on, 259
cellular wireless technologies, 461
Certificate authentication, 324
change owner tool, 194. See also icacls.exe command-line tool
"Change the time zone," 141
channels, 463
Chopchop, 465
class identifier. See CLSID
Client Certificates, other authentication methods v., 325
client protection, 225-241. See also Forefront Client Security, Microsoft; information security; Malicious Software Removal Tool; Windows Defender; Windows Live OneCare subscription service
best practices, 241
client security, 203-216. See also information security
hacks, 526-530
Client Side Mapping, SSL/TSL, 323
client-side attacks, 58-59, 526-530. See also social engineering
popularity of, 225-226
types, 58-59
client-to-DC IPsec, 451
Clipboard application, 275-276
CLSID (class identifier), 105
Collision Avoidance (CA), 463
COM. See Component Object Model
COM Elevation Monikers, 143-144, 197
Common Internet File System (CIFS), 97-98
SMB and, 97-98
CompletePC backup feature, 31
Component Object Model (COM), 143
Components key, 102
computer accounts, 109
Computer Browser service, 98, 99
computer viruses. See viruses
connection security rules, 427-428
consec, 424
Coordinated Universal Time. See UTC
CORE IMPACT, 57
"Create symbolic links," 143
Creator Owner, 24
credential hacking, 44. See also logon credential guessing/cracking
credential manager privilege for, 141
Credential Providers API, 15, 16
crimeware, 70. See also malware, automated
criminal hacking, 70, 71. See also hacker(s)
cross-site scripting (XSS) attacks, 55
cryptographic hash, 110
properties, 110
Cryptographic Operators, 24


Previous Page
Next Page

Index

D

dark screen, 133, 158
data, 101
Data Execution Protection (DEP), 6
security tweak, 536
data malformation, 55-56
DDoS attack. See distributed DoS attack
debug.exe, 216
Default Icon subkey, 106
Default User, 92
"defense in depth," 520, 523. See also information security
delayed start services, 18
delegation, 115, 116, 127, 249
feature, 316-318, 342
impersonation v., 115, 116, 127
deletion, Windows Explorer elevation and, 154-156
denial of service (DoS) attack, 57-58, 298-299
distributed, 63
web servers and, 298-299
wireless networks and, 475
deny ACEs, 184-186. See also access control list entries
Documents and Settings with, 184-185
deny operations, icacls and, 195
DEP. See Data Execution Protection
desktops, 132. See also secure desktop
definition, 211
device driver(s), 18-19
blue screens and, 19
improvements, 18-19
Device Driver Experience, 19
device installation settings, 506-508
DHTML. See Dynamic HTML
Diagnostics and Recovery Toolset, Microsoft, 222
DIALUP, 181, 182
Digest authentication, 322, 324
other authentication methods v., 325
digital certificates, 257-258
encryption and, 257-258
direct action Trojan, 63
directional rules, 427
directories, as securable objects, 172
directory traversal attacks, 296-297
representative example, 297
discretionary access control lists (DACLs), 173. See also access control lists
definition, 173
empty, 177
NULL v., 177
NULL, 177, 178
Display mixed content (setting), 271-272, 280
Display video and animation on a Web page that does not use external media player (setting), 267, 278
distributed DoS(DDos) attack, 63
Distributed John program, 48
DNS. See Domain Name System
Documents and Settings, 184-185
deny ACEs on, 184-185
domain blocking, Windows Mail, 387-390
Domain Isolation, 36-37, 446-447
Domain Name System (DNS), 89
query order, 89, 90
Domain profile, 35
domain-joined situations, FUS and, 159
Don't prompt for client certificate selection when no certificates or only one certificate exists (setting), 272, 280
DoS attack. See denial of service attack
Download signed/unsigned ActiveX controls (setting), 267, 278
Downloads (security zone setting), 268-270, 279
Automatic prompting for file downloads, 268-269, 279
File download, 269, 279
Font download, 270, 279
Drag and drop or copy and paste files (setting), 272-273, 280
Dsniff, 57
DVD player components, 215
Dynamic HTML (DHTML), 266
Dynamic WEP, 480-481


Previous Page
Next Page

Index

E

EAP. See Extensible Authentication Protocol
eavesdropping, 57. See also man-in-the-middle attacks
wireless networks and, 472-474
ECC. See Elliptical Curve Cryptography
edit.exe, 216
edlin.exe, 216
Effective Permissions tab, 172
EFI (Extended Firmware Interface), 9, 10, 74
Boot Manager, 74, 75
firmware, 74, 75
64-bit platform and, 74
EFS. See Encryption File System
802.11 Legacy wireless security recommendations, 477-480
changing AP's default Administrator Password, 480
changing AP's default SSID, 478
disabling DHCP on AP, 478-479
disabling SSID broadcasting, 479-480
enabling MAC filtering, 478
requiring user authentication passwords, 479
802.11 Wi-Fi standards, 463-464
802.11 wireless networks, 461. See also wireless networks
elevate tool, 166
elevated processes, 134
elevate.exe application, 166, 167
elevation, 130-140
auditing, 162-164
command prompt, 166-167
installers and, 166
non-admin, 137-139
prompts, 133
scripts and, 166
special topics, 139-140
of standard users, 150-151, 168
of unsigned executables, 151
Windows Explorer and attempted, 154-156
Elliptical Curve Cryptography (ECC), 26
e-mail. See also Windows Mail
defenses, 390-398
anti-malware software, 398
disable automatic download of HTML content, 394-395
file attachment blocking, 395-398
HTML content in Restricted zone, 393-394
plain-text conversion, 391-393, 535
plain-text passwords disabled, 398
protection, 351-399
best practices, 399
as spam, 226
threats, 351-384
buffer overflow, 384
embedded content, 381-382
embedded links, 382
file attachments, 58, 351-381
leaked passwords, 383
miscellaneous, 383-384
embedded content, 381-382. See also malicious file attachments
embedded links, 382
empty DACLs. See discretionary access control lists
Enable .NET Framework setup (setting), 270, 279
encryption
digital certificates and, 257-258
enhancements/support, 26-27, 257-258
hard disk, 534-535
Encryption File System (EFS), 27, 77. See also BitLocker Drive Encryption
enhancements, 27
escalation, of privileges, 54-55
Ettercap, 57
event forwarding, 29, 30
Event Log interface, 29, 30
Event Log Readers, 24
event logs, 28
Group Policy and, 497-498
improvements, 28-29
as securable objects, 173
subscriptions, 30
event numbers, 162
new, 162
event triggers, 29
events, as securable processes, 173
exploitation techniques, malicious, 43-60
Extended Firmware Interface. See EFI
Extensible Application Markup Language. See XAML
Extensible Authentication Protocol (EAP), 468
versions, 468


Previous Page
Next Page

Index

F

fast user switching (FUS), 139
domain-joined situations and, 159
feature delegation, 316-318, 342
Federal Information Processing Standard (FIPS) 140-2, 26
file associations, 104
HKCR and, 103, 104
HKCU and, 104
HKLM and, 104
file attachments, malicious. See malicious file attachments
File download (setting), 269, 279
files. See also specific files
IE file types (by file extension), 269
malware location in, 66
protection, 23
as securable objects, 172
UAC and access of, 153-154
virtualization, 25, 145
filtered tokens, 132
built-in Administrator account and, 150
filtering platform. See Windows Filtering Program
finger.exe, 216
fingerprint scanners, 14, 15
FIPS 140-2. See Federal Information Processing Standard 140-2
Firefox. See Mozilla Firefox
firewall context, 424
Firewall, Windows, 230, 403-444
with Advanced Security MMC snap-in, 422, 443
API, 424-425
best practices, 444
boot time filtering, 409-410
control panel, 419-421
Group Policy and, 422-423
IPsec and, 407, 424
IPv6 and, 36, 406-407, 412
management, 417-443
mixed/down-level environment, 438-442
management interfaces, 419-429
Netsh and, 423-424
new features/improvements, 36, 405-417
OneCare and, 238
outbound filtering and, 412-417, 525
security of, 413-417
profiles, 417-419
per-interface, 444
RPC and, 442-443
rules, 426-429
authentication exemption, 428
connection security, 427-428
directional, 427
precedence order, 428-429
server to server, 428
tunnel, 428
types, 426-429
when to use, 428
scenarios, 429-438
allowing management traffic via VPN, 437-438
blocking outbound SMB in public profile, 436-437
restricting access based on end-point, 429-436
Security Center and, 421
service hardening and, 411
stealth feature, 408
strict source mapping and, 410-411
firewalls, 404
need for, 404
policies, 207
restricting services with, 207
profiles, 417-419
Windows XP, 403, 404
folder(s). See also specific folders
low integrity, 250-251
malware locations in, 67
protection, 23
Font download (setting), 270, 279
Forefront Client Security, Microsoft, 239
FORMS authentication, 322, 324
other authentication methods v., 325
forwarded events, 29, 30
Full Volume Encryption Key (FVEK), 77
FUS. See fast user switching
fuzzers, 4
FVEK. See Full Volume Encryption Key


Previous Page
Next Page

Index

G

Gaobot, 226
GINA. See Graphical Interface for Network Authentication
Globally Unique Identifier. See GUID
GPEdit.msc (Local Security Policy), 88, 486
application order, 88
GPMC. See Group Policy Management Console v 2.0
gpmc.msc, 495
GPOs. See Group Policy objects
gpresult.exe, 489, 491
GPT. See GUID partition table
grant operations, icacls and, 195
Graphical Interface for Network Authentication (GINA), 15, 16. See also Credential Providers API
graphical user interface (GUI), 197. See also ACL UI
Grimes, Roger, 113
Group Policy, 485-518. See also specific settings
Active Directory Schema and, 514
administration tools, 221
administrative templates, 492-493
new settings, 504-510
settings that require reboot/logon, 510
application intervals, 494
best practices, 518
Client service, 496-497
Editor, 486
IE management and, 495-496
Management Console, 38, 494-495
in mixed environment, 514-515
MLGPOs, 486-491
in domain environment, 491
precedence, 489-491
NAP environment and, 516-517
new features, 38-39, 486-494
OS upgrade/rollout strategy and, 515-516
settings, 38-39, 498-510
BitLocker, 82, 83, 514
new/updated, 498-510
reboot/logon required, 510
TPM, 82, 83, 514
UAC configuration and, 150-152
system event log and, 497-498
updated features, 494-498
Web information on, 485, 518
Windows Firewall and, 422-423
Winlogon and, 496-497
Group Policy Management Console (GPMC) v 2.0, 38, 494-495
Group Policy: Management, Troubleshooting and Security (Moskowitz), 485
Group Policy objects (GPOs), 88. See also multiple local Group Policy objects
application order, 88
domain, 491
local, 486, 491
domain v., 491
types of, 486
groups, built-in
modifications of, 179
new changes, 24-25, 179
guessing. See password guessing
GUI. See graphical user interface
GUID (Globally Unique Identifier), 105, 136
GUID partition table (GPT), 74, 75


Previous Page
Next Page

Index

H

hacker(s). See also information security; malware, automated
client security and, 526-530
criminal, 70, 71
dedicated, 60-61
exploitation techniques, 43-60
IE and, 253-254, 289
intentions, 70-71
malware types and, 62-70
methodology, 60-61
PM's impact on, 253-254
popular software and, 246, 289
hard disk encryption, 534-535
hardening, 547. See also Internet Information Services 7.0; named pipes; service(s)
people, 547
Hardware key, 102
harmonics, 463
hash tables, pre-computed, 49
hashes. See specific hashes
HelpAssistant account, 181
removal of Support and, 181
hives, 101. See also registry; specific hives
abbreviations, 101
levels under, 102-103
types, 101
HKCC (HK_Current Config) hive, 107-108
HKCR (HKey_Classes_Root) hive, 103-107
file associations and, 103, 104
sections, 104-105
Trojans and, 106, 107
use of, 103
HKCU (HKey_Current_Users) hive, 107
file associations and, 104
spyware and, 107
HK_Current Config hive. See HKCC hive
HKey_Classes_Root hive. See HKCR hive
HKey_Local_Machine hive. See HKLM hive
HKey_Users hive. See HKU hive
HKLM (HKey_Local_Machine) hive, 102-103
file associations and, 104
keys in, 102-103
Software, 103
System, 103
HKU (HKey_Users) hive, 107
Howard, Michael, 4, 128
Http.sys kernel mode driver, 308
hybrid mode, 90
Hydra program, 45. See also password guessing
Hyperterminal, 215. See also telnet client


Previous Page
Next Page

Index

I

IAS. See Internet Authentication Service
icacls.exe command-line tool, 177, 201. See also subinacl tool
ACLs and, 191
resetting, 195
restoring, 192-193
saving, 191, 192
change owner with, 194
deny operations and, 195
find all ACEs granted to particular user and, 195
functionality, 191-197
grant operations and, 195
notes on, 188
remove operations and, 195-196
set integrity levels with, 196-197
shortcomings of, 199
substitute SIDs with, 193-194
ICF. See Internet Connection Firewall
ICMP. See Internet Control Message Protocol
identity, 108-109. See also logon authentication
IE. See Internet Explorer
IEAK. See Internet Explorer Administration Kit
IFRAME, 273, 280
IIS. See Internet Information Services
IIS_IUSRS, 24, 314-315
IIS_WPG, 25
impersonation, 115, 127, 219
delegation v., 115, 116, 127
Include local directory path when uploading files to a server (setting), 273, 280
"Increase a process working set," 141
Independent Software Vendors (ISV), 128
information disclosure, 55
information security, 519-547. See also security tweaks
best practices, 547
complementary approach, 523-524
"defense in depth" and, 520, 523
different views on, 526
account lockout, 539-546
anti-malware, 530-532
client security hacks, 526-530
security tweaking, 532-538
external factors, 519
risk management, 520-523, 547
enterprise, 521-523
security awareness programs, 546, 547
social engineering and, 50, 59-60, 546
examples, 59
SRP and, 524-525
strategies v. new tools, 519, 547
three-step approach, 523-525
keep attacks off box, 524
keep malicious code from communicating, 525
stop malicious code from running, 524
user education and, 524, 532
wetware, 546
infrared wireless technologies, 461
Infrastructure mode, 462-463
infrastructure, Windows, 73-117
inheritance
dangers, 175
definition, 174
Initialize and script ActiveX controls not marked as safe for scripting (setting), 267, 279
installers
elevating, 166
heuristic detection of, 151
integrity controls, 22-23, 116-117
mandatory, 22-23, 116, 146
integrity labels
low, 146
privilege for, 141
integrity levels, 116, 117, 190
setting, 196
icacls and, 196-197
integrity model, 158
integrity SIDs, 22-23
Interactive Service Detection Service, 17
International-Send UTF-8 URLs, 283, 287
INTERNET, 181, 182
Internet Authentication Service (IAS), 467, 469
Internet Connection Firewall (ICF), 403. See also Firewall, Windows
shortcomings of, 403, 404, 409
Internet Control Message Protocol (ICMP), 493. See also Network Location Awareness service
ECHO, 493, 494
Internet Explorer (IE) 7.0
ActiveX control handling, 33, 222, 223, 257
Add-on management, 256-257
advanced settings, 282-288
Browsing, 282, 287
International, 283, 287
Java (or Java-Sun), 283, 287
Security, 283-286, 287-288
summary of, 287-288
best practices, 290-291
browsers v., 245-247
defenses/recommendations, 288-289
digital certificate handling, 257-258
encryption improvements, 26-27, 257-258
file types by file extension, 269
Group Policy and, 495-496
IEAK and, 495-496
malware and, 253-254, 289
as optional component, 247
phishing filter, 32, 254-256
Protected Mode, 32, 146, 248-254, 277
malware/hackers impacted by, 253-254, 289
recommendations/defenses, 288-289
securing, 245-291
security improvements/new features, 32-34, 248-260
Security Options, 230
security zone settings, 264-281
ActiveX controls and plug-ins, 265-268, 278-279
Downloads, 268-270, 279
Java VM-Java Permissions, 270, 279
Miscellaneous, 270-275, 279-281
.NET Framework, 264-265, 277-278
recommendations, 277-281
Scripting, 275-277, 281
summary of, 277-281
User Authentication, 277, 281
security zones, 260-264
Internet site, 261-262
Local Computer, 260-261
Local intranet, 262-263
Restricted sites, 263-264
Trusted Sites, 263
shim compatibility architecture, 251-252
URL handling protections, 258-259
vulnerabilities v. market share, 247
Internet Explorer Administration Kit (IEAK), 495
IE management without, 495-496
Internet Information Services (IIS) 7.0, 293-350
access control permissions, 326-332
administration, 315-318
authentication methods, 318-325
comparison of, 325
summary of, 323-324
components, 302-307
default, 305-306
individual descriptions, 302-305
configuration/tightening of, 339-344
defending, 332-348
summary of steps for, 333
Handler Permissions, 326-331
summary/usage of, 331
hardening procedures, 332-348
application installation/securing, 347
cleaning/testing, 347
deploying to production, 347-348
host firewall configuration, 335
log file/firewall monitoring, 348
minimal configuration on IIS, 336
network/perimeter security configuration, 333-334
OS hardening, 337-339
OS installation, 334-335
patch installations, 336-337
penetration tests, 347
physical security, 334
remote administration configuration, 335-336
summary of, 348-350
updated hardware drivers, 334
Web site securing, 344-346
web-server specific, 39-344
installation of, 301
additional features, 340
introduction, 299-300
modules, 340-341
list/description of, 340
new features/improvements, 34, 57, 300-301
NTFS permissions and, 332
strengthening, 342-343
protocol listeners, 307-309
versions, 300
web component minimization, 342
web server threats, 293-299
Internet site security zone, 261-262. See also security zone settings
Interprocess Communications mechanism. See IPC mechanism
Interprocess Communications Share. See IPCS
IP version 6 (IPv6), 36, 412
Windows Firewall and, 36, 406-407, 412
IPC (Interprocess Communications) mechanism, 207. See also named pipes
IPCS (Interprocess Communication Share), 97
IPsec, 407
client-to-DC, 451
definition, 407
Windows Firewall and, 407, 424
IPv6. See IP version 6
isolation. See also information security; Server and Domain Isolation
Domain, 36-37, 446-447
Domain and Server, 445-459, 524, 526, 530, 531
Server, 447-448
Session 0, 210-213
sessions, 16-17, 211-212
UAC and process, 158, 169
ISV. See Independent Software Vendors
IUSR_computername, 314-315


Previous Page
Next Page

Index

J

Java (or Java-Sun)-Use JRE x.x for [applet], 283, 287
Java applets, 277
scripting of, 277, 281
Java Virtual Machine (JVM) component, 270
Java VM-Java Permissions, 270, 279
Johansson, Jesper, 174
John the Ripper program, 48, 61
junction points, 23, 143, 184, 185, 186
junk mail detection, Windows Mail, 386-387
JVM component. See Java Virtual Machine component


Previous Page
Next Page

Index

K

Keeping Your Business Safe From Attack: Passwords and Permissions (Grimes), 113
Kerberos, 109, 111, 112, 431, 433, 435
kernel objects, 173
Kernel Patch Protection, 39
keylogging, 50
keys, 101. See also specific keys
Kismet, 57
Konqueror, 246


Previous Page
Next Page

Index

L

LAN Manager (LM), 14, 110, 112
disabled, 14
hash, 110
LAND attacks, 58
Launching applications and unsafe files (setting), 273, 280
Launching programs and files in an IFRAME (setting), 273, 280
least privilege, 128, 179, 525, 526, 528, 530, 531. See also information security; User Account Control
LeBlanc, David, 4, 449
leinstal.exe, 252
leuser.exe, 252
Link-Layer Topology Discovery, 35
Link-Layer Topology Discovery Responder, 35
LM. See LAN Manager
LMCompatibilityLevel setting, 534
Local Computer Policy, 486
Local Computer security zone, 260-261. See also security zone settings
Local intranet security zone, 262-263. See also security zone settings
Local Security Policy (GPEdit.msc), 88, 486
application order, 88
Local Service account, 92, 205
Local System account, 92, 205
logon architecture
improvements, 14-17
process, 16
session isolation, 16-17
logon authentication, 108-114
logon credential guessing/cracking, 44-51
logon scripts, 516
UAC and failure of, 516
LogonUI, 15, 16
logs, 29
Longhorn server, 514
future improvements, 40
Loose XAML (setting), 264, 277
LophtCrack, 57, 112
low integrity folders, 250-251
Lynx, 246


Previous Page
Next Page

Index

M

MAC. See Media Access Control
MACLs. See mandatory access control lists
Mail. See e-mail; Windows Mail
malicious code, 524. See also information security
three-step approach for management of, 524-525
malicious exploitation techniques, 43-60
malicious file attachments, 58, 351-384. See also e-mail
file extension tricks, 380-381
number of, 352
table list
details of file type, 352-379
file extension, 352-379
file type, 352-379
risk level, 352-379
Malicious Software Removal Tool (MSRT), 13-14, 225-229
command-line switches, 228
download, 227
malware, automated, 4, 62-71, 225. See also adware; bot(s); client protection; hacker(s); information security; spyware; Trojans; viruses; Windows Defender; worms
anti-, 524, 531-532
Microsoft and, 239-240
bootable, 76
business v. home computer attacks, 520
criminal gain through, 64, 70, 71
defense, 241, 520
e-mail defense against, 398
hybrid, 63
IE and, 253-254, 289
intentions of, 64, 70, 71, 520
locations modified by, 65-70
application areas, 66
file areas, 66
folder areas, 67
other, 67
registry keys, 67-70
PM's impact on, 253-254
removal procedures, 71
as side-effect install, 240
types, 62-70
UAC and, 122, 123, 158, 169
wireless networks and, 474-475
mandatory access control lists (MACLs), 173. See also access control lists
definition, 173
mandatory integrity controls (MICs), 22-23, 116, 146. See also integrity controls
man-in-the-middle (MitM) attacks, 27, 50, 57
Margosis, Aaron, 128
Master Boot Record (MBR), 74, 75
MBR. See Master Boot Record
Media Access Control (MAC) addresses, 478
media devices, controlled, 19, 525
Message Integrity Code (MIC), 466
Metasploit Framework (MSF), 53, 57
web interface, 53
MIC. See Message Integrity Code
Microsoft, anti-malware and, 239-240
Microsoft Desktop Optimization Pack (MSDOP), 221-222
technologies, 221-222
Web information on, 222
Microsoft Management Console (MMC), 486
Microsoft Security Web Site, 230
Quick Link, 230
Microsoft Windows Internals, Fourth Edition (Russinovich, Solomon), 73
MICs. See mandatory integrity controls
Milw0rm Web site, 52
MIME type identifier, 105
MIMO. See Multimedia In Multimedia Out
Miscellaneous (security zone setting), 270-275, 279-281. See also specific settings
misconfiguration, 56
application, 56-57
OS, 56-57
MitM attacks. See man-in-the-middle attacks
mixed/down-level environment, Windows Firewall and, 438-442
MLGPOs. See multiple local Group Policy objects
Mlink.exe utility, 23
MMC. See Microsoft Management Console
"Modify an object label," 141
Moskowitz, Jeremy, 485, 518
Mozilla Firefox, 245, 246
security of, 246
vulnerabilities v. market share, 247
Msascui.exe, 233
MSDOP. See Microsoft Desktop Optimization Pack
MSF. See Metasploit Framework
Msmpeng.exe, 233
MSN Explorer, 214
MSRT. See Malicious Software Removal Tool
Multimedia In Multimedia Out (MIMO), 464
multiple local Group Policy objects (MLGPOs), 486-491. See also Group Policy
in domain environment, 491
precedence, 489-491
Web information on, 491


Previous Page
Next Page

Index

N

name resolution, 89-90
NetBIOS, 90
named pipes, 97
definition, 207
hardening, 207-208
as securable objects, 173
NAP. See Network Access Protection
Navigate sub-frames across different domains (setting), 273, 280
Nessus, 57
.NET Framework, 265
client software, 265
enable setting, 270, 279
security zone settings, 264-265, 277-278
Loose XAML, 264, 277
reliant components-Run components signed/not signed with Authenticode, 265, 278
XAML browser applications, 264, 277
XPS documents, 264-265, 278
NetBios
name resolution, 90
NetMeeting, 214-215. See also Windows Meeting Space
Net.MSMQ protocol listener, 309
Net.P2P protocol listener, 308
Net.Pipe protocol listener, 308
Netsh, 423
Windows Firewall and, 423-424
Net.Tcp protocol listener, 308
NETWORK, 182
Network Access Protection (NAP), 37, 471
Group Policy and, 516-517
network domains, 35. See also specific domains
isolation, 36-37
Network Location Awareness (NLA) service, 35, 87, 493-494
network location SIDs, 181-182
new, 181-182
network mapping tool, 35. See also Link-Layer Topology Discovery Responder
Network Policy Server (NPS), 467, 469, 471
network ports
as securable objects, 173
network profiles, 91
Network Service account, 92, 205
network sniffing. See sniffing, network
network threat modeling, 450, 451
Nigerian scams, 383
NLA. See Network Location Awareness
Nmap, 60, 61
No eXecute (NX) mechanism, 6
nodes, 462. See also Wi-Fi
NPS. See Network Policy Server
NT hashes, 110
NT LAN Manager (NTLM), 110, 112
NT ServiceTrusted Installer, 181. See also Trusted Installer service
NTFS (Windows NT file system)
changes/improvements, 23-24
permissions, 115
Share v., 115
NTFS permissions, 332
IIS and, 332
share permissions v., 115
strengthen, 342-343
Ntfsdos, 77
NTLM. See NT LAN Manager
Ntoskrnl.exe, 75, 76
NULL DACLs. See discretionary access control lists
NX mechanism. See No eXecute mechanism


Previous Page
Next Page

Index

O

OAR. See Owner Access Restriction
objects, 171. See also securable objects; specific objects
Office Live Communicator, 214
OneCare. See Windows Live OneCare subscription service
Open files based on content, not file extension (setting), 274, 280
Opera, 246
vulnerabilities v. market share, 247
operating system (OS)
files, 184
Trusted Installer and, 184
Group Policy and upgrade/rollout strategy, 515-516
IIS
hardening, 337-339
web server services, 337-339
misconfiguration, 56-57
vulnerabilities, 54-56
web server, 295
OS. See operating system
OS kernel, Vista, 7, 75
outbound filtering, Windows Firewall and, 412-417, 525
Outlook Express, 31. See also Windows Mail
Owner Access Restriction (OAR), 24
OWNER RIGHTS, 182-183, 201
SID, 182-183


Previous Page
Next Page

Index

P-Q

P2P networking. See peer-to-peer networking
package point and print functionality, 506
Passport services, 34, 259. See also CardSpace; Windows Live ID
password authentication, 14, 16
password cracking, 14, 44, 48-50. See also logon credential guessing/cracking
benefits of, 48, 50
methodology, 48
programs, 48
speed of, 48, 49
tools, 112, 113
ebook for, 113
password dictionaries, 47
attacks, 46
password guessing, 44-47
attacks, 299
web servers and, 299
automated, 44-46
problems with, 47
types of, 46
password hacking methods, 50-51
password hashes, 48
LM, 110
NT, 110
password hybrid attacks, 46
password storage, 110
password strength, 533, 535
account lockout and, 541-545
passwords, leaked, 383. See also malicious file attachments
PatchGuard, 39
patching
hot, 28
management, 28
PC/AT BIOS, 74, 75. See also EFI
Peer Name Resolution Protocol (PNRP), 37
peer-to-peer (P2P) networking, 37
people, hardening, 547
perimeters, SDI and, 448-449
permissions. See also NTFS; Share permissions
ACLs and, 24, 171
default, 186-189, 201
changes to, 186-189
modification of, 188-189, 201
phishing attacks, 383
phishing detection, Windows Mail, 385-386
phishing filter, 32, 254
anti-, 254-256
security zone setting, 274-275, 281
Piaget, Chris, 212
plain-text conversion, e-mail, 391-393. See also e-mail
Platform Software Developers Kit, 174
PM. See Protected Mode
PNRP. See Peer Name Resolution Protocol
Ponemon Institute, 77
Pop-up Blocker
security zone setting, 275, 281
portscanning, 409
POSIX subsystem
optional, 214
POST. See Power-on-Self Test
post-boot startup, 87
Power Users, 25, 180, 199
end of, 147, 180
Power-on-Self Test (POST), 74, 75
preferred networks, 463
Pre-Shared Key (PSK), 466
printer deployment, 506
Private network domain, 35
privilege(s). See also specific privileges
account rights v., 140
common task delegations and, 140-143
escalation, 54-55
new, 140-143
services with less, 205-207
Process Tracking auditing, 538
processes, 173. See also specific processes
as securable objects, 173
profiles, firewall, 417-419. See also Firewall, Windows; specific profiles
per-interface, 444
Protect Your PC marketing campaign, 128, 526
Protect Your Windows Network: From Perimeter to Data (Johansson, Riley), 174
Protected Mode (PM), 32, 146, 248-254, 277. See also Internet Explorer 7.0
low integrity folders, 250
malware/hackers impacted by, 253-254, 289
shim compatibility architecture, 251-252
turn off, 251
protected processes, 7
Task Manager and, 7
protocol listeners, 307-309. See also specific protocol listeners
protocols, 295
vulnerabilities, 295-296
PSK. See Pre-Shared Key
Public network domain, 35
Pwdump, 112


Previous Page
Next Page

Index

R

rainbow tables, 49-50
RATs. See remote access Trojans
Rbot, 226
RDP. See Remote Desktop Protocol
ReadyBoost technology, 19
USB flash memory drives and, 19
Recovery key, 79. See also Boot-up key
REG_DWORD, 101
Regedit.exe, 101
registry, 101
ACLs, 199-200
protection, 23
replacement, 108
structure, 101-108
virtualization, 25
registry keys, 173
list, 67-70
malware in, 67-70
low integrity, 250
as securable objects, 173
REG_MULTI_SZ, 102
REG_SZ, 102
relative identifier (RID), 124, 125. See also Administrator account, built-in 500, 124, 146, 180
reliant components-Run components signed/not signed with Authenticode (setting), 265, 278
remote access
UAC and, 148, 160
remote access Trojans (RATs), 63
Remote Assistance (RA), 148-149
UAC and, 149
Remote Desktop, 148-149
Remote Desktop Protocol (RDP), 26, 27
Remote Procedure Call. See RPC
remove operations, icacls and, 195-196
Request Filtering, 343-344
configuration, 343-344
Restart Manager, 28, 216-218, 222
Web information on, 218
RESTRICTED SID, 199, 200
Restricted sites security zone, 263-264. See also security zone settings
restricted token, 199, 200
Resultant Set of Policy (RSOP) tools, 450, 489
RID. See relative identifier
rights, 140. See also account rights
Rights Management Service (RMS), 27
Riley, Steve, 174, 448
risk management, 520-523, 547. See also information security
enterprise, 521-523
RMS. See Rights Management Service
roaming profiles, 91
robot code, 63. See also bot(s)
rogue Internet links, 58
rootkits, 65, 129, 226
routing compartmentalization, 36
RPC (Remote Procedure Call), 95-96
disabling, 96
Endpoint Mapper service, 205, 206
Windows XP, 205
importance, 96
settings, 508
Windows Firewall and, 442-443
Rpc-dump.exe, 97
RSOP. See Resultant Set of Policy tools
rsop.msc, 489, 491
rules. See specific rules
rules, Windows Firewall, 426-429
authentication exemption, 428
connection security, 427-428
directional, 427
precedence order, 428-429
server to server, 428
tunnel, 428
types, 426-429
when to use, 428
Run ActiveX controls and plug-ins (setting), 268, 279
Russinovich, Mark, 19, 73


Previous Page
Next Page

Index

S

SA customers. See Software Assurance customers
SACLs. See System ACLs
Safari, 246
vulnerabilities v. market share, 247
Safe Exception Handling switch (/SafeSEH), 5
safe mode
built-in Administratoraccount in, 146, 147
SAL. See Standard Annotation Language
SAM. See Security Accounts Manager
SAMjuicer, 112
SCM. See Service Control Manager
Script ActiveX controls marked safe for scripting (setting), 268, 279
Scripting (security zone setting), 275-277, 281
Active Scripting, 275, 281
Allow programmatic clipboard access, 275-276, 281
Allow status bar updates via script, 276, 281
Allow websites to prompt for information using scripted window, 276, 281
Scripting of Java applets, 277, 281
Scripting of Java applets (setting), 277, 281
scriptlets, 266, 278
scripts
elevating in, 166
Sdbot, 226
SDDL. See Security Descriptor Definition Language
SDI. See Server and Domain Isolation
SDL. See Security Development Lifecycle
SDs. See security descriptors
SeChangeNotifyPrivilege, 186
SeCreateSymbolicLink-Privilege, 143
securable objects, 172. See also objects
examples of, 172-173
SDs and, 173-174
secure desktop, 21, 132-133
switch to, 133, 134
disabling, 133, 152
UAC dialog boxes and, 21
Secure Windows Initiative Attack Team (SWIAT), 4
Security (IE advanced settings), 283-286, 287-288
Security Accounts Manager (SAM), 77
Active Directory v., 112
key, 102-103
security awareness programs, 546, 547. See also information security
Security Center, 230-231
features, 230
view/configure, 230-231
Windows Firewall and, 421
Security Descriptor Definition Language (SDDL), 174
discussion of, 174
learn, 201
security descriptors (SDs), 173-174
securable objects and, 173-174
Security Development Lifecycle (SDL), 3-4
security features, Vista
essential, 128
new, 3-42
future, 40
Group Policy settings, 38-39
host-based, 8-31
IE 7, 32-34, 248-260
IIS 7, 34
networking, 34-38
64-bit platform, 39-40
Windows Mail, 31
Security Guide, Vista, 510-513, 547. See also Group Policy
benefits of, 511
importance of, 513
limitations, 511-513
need for, 511
security identifiers (SIDs), 18, 124-125. See also specific security identifiers
ACEs and, 174
components of, 124-125
definition, 124
icacls and substitute, 193-194
integrity, 22-23
network location, 181-182
new, 181-182
NT ServiceTrusted Installer, 181
OWNER RIGHTS, 182-183
Security key, 103
security options, Vista, 498-504
with modified defaults, 498, 500-503
new, 499-500
removed, 504
security policies
application of, 88
security principals, 171
security settings, default, 12-13
security strategies. See information security
security tokens
changes to, 189-190
contents, 125-127
Whoami command and, 125
security tweaks, 532-538. See also information security
auditing, 533
bad, 536-538
ACL changes, 536-537
disabling MSV1_0, 537
disabling Process Tracking auditing, 538
too many user rights/privileges, 537
UAC disabling, 538
don't use public, shared computers, 536
e-mail conversion to plain text, 391-393, 535
hard disk encryption, 534-535
LMCompatibilityLevel setting, 534
password strength, 533, 535
remove logon privileges from service accounts, 534
run services on non-default ports, 535-536
SDI, 534
turn on DEP, 536
security zone settings, 264-281. See also specific settings
ActiveX controls and plug-ins, 265-268, 278-279
Downloads, 268-270, 279
Java VM-Java Permissions, 270, 279
Miscellaneous, 270-275, 279-281
.NET Framework, 264-265, 277-278
recommendations, 277-281
Scripting, 275-277, 281
summary of, 277-281
User Authentication, 277, 281
security zones, 260-264
Internet site, 261-262
Local Computer, 260-261
Local intranet, 262-263
Restricted sites, 263-264
Trusted Sites, 263
SeIncreaseWorkingSet-Privilege, 141
sender white/black lists, Windows Mail, 387
SeRelabelPrivilege, 141
Server and Domain Isolation (SDI), 445-459, 530, 531, 534, 536. See also information security
AuthIP and, 451-452
best practices, 459
configuration user interface, 453-458
documentation, 446
Domain Isolation and, 36-37, 446-447
negotiation flow and, 452-453
network threat modeling and, 450, 451
overview, 445-448
perimeters and, 448-449
rules, 454-458
domain, 454-457
server, 457-458
security tweak, 534
Server Isolation and, 447-448
value of, 458-459
Server Core, 40
Server Message Block (SMB) 2.0, 38, 97-98
access, 148
UAC and, 148
CIFs and, 97-98
disabling, 98
Server service, 98, 99
disabling, 99
server to server rules, 428
service(s), 92-94. See also specific services
accounts, 92, 93
complete list, 17
delayed start, 18
desktop interaction with, 93, 94
essential, 94-100
failure, 94
hardening, 17-18, 92, 181, 204, 222
features, 204-207
Windows Firewall and, 411, 525
less privileged, 205
number of, 92
privilege reduction in, 205-207
restriction, 93
firewall policies and, 207
security, 17-18
SIDs, 204-205
write-restricted tokens and, 207
Service Control Manager (SCM), 18, 92
Service Host Process. See Svchost
Service Set Identifier (SSID), 462
broadcasting, 479-480
disabling, 479-480
Session 0 isolation, 210-213, 222
mechanics of, 212-213
sessions, 210-211
isolation, 16-17
need for, 211-212
security, 16-17
SeTimeZonePrivilege, 141-142
SeTrustedCredManAcces-Privilege, 141
share permissions, 115
default, 189
NTFS permissions v., 115
Sharing tab, 190
shatter attacks, 212. See also Session 0 isolation
ShellOpenCommand subkey, 106
shoulder-surfing, 50
SIDs. See security identifiers
Silentrunner.vbs script, 70
http://www.simplicita.com, 63
64-bit platform
EFI on, 74
improvements to, 39-40
smart cards
support, 15, 16
SMB. See Server Message Block
sniffing attacks, web servers and, 297-298
sniffing, network, 48, 50, 111
Cain & Abel and, 50, 51
Kismet and, 57
social engineering, 50, 59-60, 546. See also information security
examples, 59
sockets, permissions, 24
SoftGrid, Microsoft, 221
Software Assurance (SA) customers, 221, 223
Software channel permissions (setting), 274, 281
Software Explorer, 235
Windows Defender and, 235, 236
Software Restriction Policies (SRP), 524-525, 529. See also information security
software, unintended consequences of, 56
Solomon, David, 73
spam, 226
Spectorsoft, 64
SpyNet, 12, 231, 233. See also Windows Defender
online community, 13
spyware, 64
browser cookies, 237
HKCU and, 107
SQL Slammer, 62, 448
SRP. See Software Restriction Policies
SRT. See Startup Recovery Tool
SSID. See Service Set Identifier
SSL VPNs, 448
SSL/TSL Client Side Mapping, 323
Standard Annotation Language (SAL), 4
coding and, 4
website information, 4
standard users
elevation of, 150-151, 168
Startup Recovery Tool (SRT), 10, 11
stealth feature, Windows Firewall, 408
Storage Root Key, 78
strict source mapping, Windows Firewall and, 410-411
SUA. See Subsystem for Unix-Based Applications
subinacl tool, 199, 201. See also icacls.exe command-line tool
ACLs management and, 199, 201
subjects, 171. See also security principals
subkeys, 101. See also specific subkeys
Submit non-encrypted form data (setting), 274, 281
Subsystem for Unix-Based Applications (SUA), 28
subtrees, 101. See also hives
sudo, 160-162
UAC v., 160-162
Sullivan, Kevin, 221
Support account, 181
removal of HelpAssistant and, 181
Svchost (Service Host Process), 94-95. See also RPC
processes, 95
SWIAT. See Secure Windows Initiative Attack Team
symbolic links, 23, 143
creation, 143
privilege for, 143
user profile, 91
SYN-ACK packet, 404
Sysinternals, 70, 235
system access control lists (SACLs), 173. See also access control lists
definition, 173
modification of, 199
System ACLs (SACLs), 24
system recovery tools, improvements on, 10-11
System Restore Points, 24


Previous Page
Next Page

Index

T

Tablet PC Optional Components, 215
Task Manager
protected processes and, 7
security improvements, 30-31
Tasklist /svc, 95
TCP/IP stack
with IPv6, 36
rebuilt, 34, 35, 36
telnet client, 215
optional, 214
telnet server, optional, 214
template embedding, 493
ADMX files and, 493
Temporal Key Integrity Protocol (TKIP), 466
Terminal Services, 508
Group Policy settings, 508-510
TFTP client, optional, 214
thinking about security. See information security
Threat Code (http://www.threatcode.com), 169, 206
threat modeling, 3-4, 56
network, 450, 451
time
UTC, 142
Zulu, 142
time zone modification privilege, 141-142
TKIP. See Temporal Key Integrity Protocol
tokens. See security tokens; specific tokens
TPM. See Trusted Platform Module
Tpm.msc, 12, 80
Trojans, 62-63, 225
direct action, 63
HKCR and, 106, 107
RATs, 63
Trusted for Delegation, 116
Trusted Installer service, 26, 181
new feature, 181
NT SERVICE, 181
SID of, 181
OS files and, 184
Trusted Platform Module (TPM), 78. See also BitLocker Drive Encryption
chip, 11, 12, 78
initialization, 80, 81, 82
Web site information, 78
enabling steps for BitLocker and, 80-87
Group Policy settings, 82, 83, 514
password creation, 81, 82
recovery keys, 514
Trusted Sites security zone, 263. See also security zone settings
tunnel rules, 428


Previous Page
Next Page

Index

U

UAC. See User Account Control
UIAccess. See User Interface access
UMDF. See User-Mode Driver Framework
unintended software consequences, 56
Unix, on Windows, 28. See also Subsystem for Unix-Based Applications
URL Filtering, 343. See also Request Filtering
URL handling protections, 258-259
USB flash memory drives, 10, 19
boot disk, 549
WinPE and building, 549-554
ReadyBoost and, 19
Use phishing filter (setting), 274-275, 281. See also phishing filter
Use Pop-up Blocker (setting), 275, 281
User Access Control Status, 230
User Account Control (UAC), 20-21, 121-169
applications and leveraging, 164-167
basics, 123-124
best practices, 168-169
disabling, 152, 156-157, 159
consequences of, 157
facts about, 122-123
file access and, 153-154
frequently asked questions, 153-164
goals/purpose of, 129-130, 168
Group Policy configuration, 150-152
importance of, 168
introduction, 121-123
least privilege and, 128, 179, 525, 526, 528, 530, 531
logon script failure and, 516
malware and, 122, 123, 158, 169
non-admins and, 129-130
process isolation and, 158, 169
purpose/goals of, 129-130, 168
RA and, 149
remote access and, 148
Secure Desktop and, 21
SMB access and, 148
sudo v., 160-162
system-wide setting of, 159
User Account Control: AdminApproval Mode for the Built-in Administrator Account, 150
User Account Control: Behavior of the Elevation Prompt for Administrators in Admin Approval Mode, 150
User Account Control: Behavior of the Elevation Prompt for Standard Users, 150-151
User Account Control: Detect Application Installations and Prompt for Elevation, 151
User Account Control: Only Elevate Executables that Are Signed and Validated, 151
User Account Control: Only Elevate UIAccess Applications that Are Installed in Secure Locations, 152
User Account Control: Run All Administrators in Admin Approval Mode, 152
User Account Control: Switch to the Secure Desktop when Prompting for Elevation, 152
User Account Control: Virtualize File and Registry Write Failures to Per-User Locations, 152
User Authentication, 277
security zone settings, 277, 281
User data persistence (setting), 275, 281
User Experience (UX), Vista, 7-8
User Interface access (UIAccess), 152, 157
user profiles, 90-92
symbolic links and, 92
User-Mode Driver Framework (UMDF), 19
users, built-in
modifications of, 179
new changes, 24-25, 179
UTC (Coordinated Universal Time), 142
UX. See User Experience


Previous Page
Next Page

Index

V

values, 101
virtualization, 145
disabling, 152
file, 25, 145
registry, 25
removal of, 145
viruses, 62, 524. See also Windows Live OneCare subscription service
anti-virus programs, 220-221, 524
limitations of, 221
boot, 76
OneCare and scanning, 238
Vista. See Windows Vista
VMK. See Volume Master Key
Volume Master Key (VMK), 77, 78
Volume Shadow Copy service, 24
VPN protocols, 481
vulnerabilities. See also data malformation; information disclosure; privilege(s); unintended software consequences
application, 54-56
defense, 57
OS, 54-56
testing tools, 53, 57


Previous Page
Next Page

Index

W

WAIK. See Windows Automated Installation Kit
web servers, 293-294
buffer overflows, 296
DoS attacks, 298-299
OS vulnerabilities, 295
password guessing attacks, 299
sniffing attacks, 297-298
threats, 293-299
list of, 294
Web sites in less privileged web content zone can navigate into this zone (setting), 275, 281
Wecsvc service. See Windows Event Collector service
WEP. See Wired Equivalent Privacy
wetware, 546. See also information security
wf.msc, 422
WFP. See Windows File Protection; Windows Filtering Program
Whoami /all command, 114
security token and, 125
Wi-Fi, 461-471. See also wireless networks
Ad-Hoc mode, 462-463
Alliance, 462
best practices, 482
802.11 network technologies, 461
802.11 standards, 463-464
comparison of, 464
types, 463
Infrastructure mode, 462-463
security standards, 464-471
setup diagram, 462
terminology/technologies, 461-471
Wi-Fi Protected Access. See WPA
Wi-Fi Protected Setup (WPS), 466, 467
Window Stations (winsta), 211
Windows authentication, 322-323, 324
other authentication methods v., 325
Windows Automated Installation Kit (WAIK), 549, 550. See also Windows Pre-Installation Environment
Windows Backup. See Backup, Windows
Windows CardSpace. See CardSpace
Windows Defender, 13, 14, 230, 231-238. See also Windows Live OneCare subscription service
accuracy, 236-237
heuristic scanning, 235
OneCare and, 238, 239
real-time scanning, 232
areas of, 232-233
Software Explorer feature, 235, 236
startup program information by, 236
Windows Event Collector (Wecsvc) service, 30
Windows Explorer, 154
elevation motions for, 154-156
deletion and, 154-156
Windows Fax and Scan service, 215
Windows File Protection (WFP), 25, 26, 209. See also Windows Resource Protection
WRP v., 209
Windows Filtering Program (WFP), 405-407
architecture diagram of, 406
Windows Firewall. See Firewall, Windows
Windows infrastructure, 73-117
Windows Installer 4.0, 28
Windows Live ID, 34
Windows Live Mail, 352
Windows Live Messenger, 214
Windows Live OneCare subscription service, 238-239
anti-virus scanning, 238
firewall, 238
Windows Defender and, 238
Windows Mail, 31. See also e-mail
domain blocking, 387-390
e-mail storage in, 390
introduction, 384-390
junk mail detection, 386-387
phishing detection, 385-386
security features, 384-390
Windows Meeting Space, 214, 215
Windows Messenger, 214. See also Office Live Communicator
Windows Modules Installer, 181. See also Trusted Installer service
Windows Name Service (WINS), 90
Windows NT file system. See NTFS
Windows Pre-Installation Environment (WinPE), 10-11, 549
bootable USB flash drive, 549
building, 549-554
features, 10-11
packages in, 551
Windows Presentation Foundation (WPF) platform, 264
Windows Protected Media Path (WMPM), 7
Windows Recovery Environment (WinRE), 10
Windows Remote Management (WinRM) service, 30
Windows Resource Protection (WRP), 26, 209-210
Web information on, 210
WFP v., 209
Windows Shared View, 37
Windows Sidebar, 215
Windows Terminal Services, 148. See also Remote Desktop
Windows Vista. See also access control lists; Group Policy; information security; security features, Vista; wireless networks
ACLs, 114-117, 171-201
client protection, 225-241
components
new, 215
optional, 213-214, 214
reduction of, 213-214
removed, 214-215
undesirable, 215-216
information security, 519-547
security features, 3-42
Security Guide, 510-513
security options, 498-504
wireless improvements in, 476-477
Windows XP, 178. See also access control lists
ACL UI, 197
ACLs, 178-179
default, 179
problems in, 178-179
firewall, 403, 404
WindowsSystem32 files
protection of, 23
Winload.exe, 9, 75, 76
Winlogon, 496. See also Group Policy
Group Policy and, 496-497
WinPE. See Windows Pre-Installation Environment
WinRE. See Windows Recovery Environment
Winresume.exe, 10
WinRM service. See Windows Remote Management service
WINS. See Windows Name Service
winsta. See Window Stations
Wired AutoConfig, 467
Wired Equivalent Privacy (WEP), 465-466, 480-481
Dynamic, 480-481
Wireless Fidelity, 462. See also Wi-Fi
wireless networks, 482. See also Wi-Fi
best practices, 482
securing, 37, 477-481
threats, 471-475
DoS attacks, 475
eavesdropping, 472-474
malware, 474-475
unauthorized access, 474
Vista improvements for, 476-477
Wireshark, 57
WMF worm, 228, 229
WMI filters, 440-441
version specification, 441
Work network domain, 35
worker processes, 309
working set, privilege for, 141
Workstation service, 98, 99, 205
disabling, 98-99
worms, 62. See also specific worms
WPA (Wi-Fi Protected Access), 466, 481
Enterprise Mode, 467-471
Personal Mode, 466-477
using, 481
WPA2 Enterprise Mode, 467-471
WPA2/802.11i, 466, 481, 482
WPF platform. See Windows Presentation Foundation platform
WPS. See Wi-Fi Protected Setup
write-restricted tokens, 207
services with, 207
WRP. See Windows Resource Protection


Previous Page
Next Page

Index

X-Y

XAML (Extensible Application Markup Language), 264
XAML browser applications (setting), 264, 277
XML Paper Specification. See XPS
XP. See Windows XP
Xprobe2, 60
XPS (XML Paper Specification), 264-265
documents (setting), 264-265, 278
XSS attacks. See cross-site scripting attacks


Previous Page
Next Page

Index

Z

ZoneAlarm, 240
zones. See security zones; time zone
Zulu time, 142


List of Figures

Chapter 1: New Security Features

Figure 1-1: DEP can be enabled for all processes that are not specifically exempted.
Figure 1-2: Windows Defender is included in Windows Vista.
Figure 1-3: The new Windows logon process provides more granular hooks for enhancement.
Figure 1-4: The UAC elevation dialog box is on the secure desktop.
Figure 1-5: The new Event Log interface is a vast improvement.
Figure 1-6: Windows CardSpace can represent credentials for many sites as "cards."

Chapter 2: How Hackers Attack

Figure 2-1: Hydra automated password guessing program being used against a Telnet service
Figure 2-2: Cain & Able being used to crack Windows password hashes
Figure 2-3: Plain-text FTP passwords caught by Cain & Able using network traffic eavesdropping techniques
Figure 2-4: Milw0rm Web site
Figure 2-5: Metasploit Framework web interface
Figure 2-6: Bot phoning home

Chapter 3: Windows Infrastructure

Figure 3-1: Windows Vista boot sequence summary
Figure 3-2: New Trusted Platform Module (TPM) console
Figure 3-3: Initializing the Trusted Platform Module (TPM) chip
Figure 3-4: Creating a Trusted Platform Module (TPM) password
Figure 3-5: Saving the TPM password to media
Figure 3-6: TPM initialization in process
Figure 3-7: TPM and BitLocker group policy settings
Figure 3-8: Enabling BitLocker using the BitLocker Drive Encryption applet
Figure 3-9: BitLocker startup options
Figure 3-10: Saving BitLocker key to USB
Figure 3-11: Saving a BitLocker recovery key
Figure 3-12: Enabling BitLocker system check
Figure 3-13: Initial BitLocker encryption in process
Figure 3-14: Confirming BitLocker encryption status in disk management
Figure 3-15: Local Security Policy and GPO application order
Figure 3-16: DNS query order
Figure 3-17: Example of allowing a service to interact with the desktop
Figure 3-18: Example of a service sending a message after it fails more than two times
Figure 3-19: Tasklist /svc revealing svchost hosted processes
Figure 3-20: Example of Autoruns utility
Figure 3-21: Main Registry hives
Figure 3-22: Example HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Figure 3-23: Partial access token listing using Whoami /all

Chapter 4: User Account Control

Figure 4-1: UAC approval dialog box for administrator in admin-approval mode
Figure 4-2: Modifying or deleting files in %ProgramFiles% and %windir% does not work even as an administrator.
Figure 4-3: Administrators, by default, have a token that marks the Administrators SID for Deny.
Figure 4-4: A user can initiate elevation of a task by right-clicking the program and selecting "Run as administrator."
Figure 4-5: Elevation prompts are shown on the secure desktop by default.
Figure 4-6: An elevated process has a full administrative token.
Figure 4-7: An unsigned binary has a different elevation dialog box.
Figure 4-8: Unsigned driver installation dialog box
Figure 4-9: IE will prompt for installation of ActiveX controls.
Figure 4-10: The IE ActiveX Control installation prompt is not particularly useful.
Figure 4-11: The elevation prompt when running as a standard user
Figure 4-12: Elevated tasks run on the standard user's desktop.
Figure 4-13: The Windows Event Log shows the times in the local time zone, but computes them from the internally stored UTC time.
Figure 4-14: Task Manager uses a COM Moniker to allow users to use only a subset of the functionality without elevating.
Figure 4-15: Task manager launched elevated
Figure 4-16: Right-click on Windows Explorer.
Figure 4-17: Attempting to elevate Windows Explorer
Figure 4-18: Attempting to delete a protected file from an "elevated" Explorer window
Figure 4-19: You can turn off UAC with the User Accounts control panel applet.
Figure 4-20: Windows Vista supports Fast User Switching even on domain-joined computers.
Figure 4-21: You can use the elevate.exe application to elevate any application from a command line.
Figure 4-22: With the elevate.exe tool, it is easy to get an elevated command prompt anywhere.

Chapter 5: Managing Access Control

Figure 5-1: The Effective Permissions tab evaluates permissions for any user.
Figure 5-2: A NULL DACL means that the object has not been secured.
Figure 5-3: The Sharing tab received a makeover in Windows Vista.
Figure 5-4: ACL UI dialog box in Windows XP
Figure 5-5: ACL UI dialog box from Windows Vista
Figure 5-6: Modifying the audit settings in Windows Vista always requires elevation.
Figure 5-7: The Registry ACLs include an ACE for RESTRICTED in several places.

Chapter 6: Application Security

Figure 6-1: Security token for RPC Endpoint Mapper on Windows Vista
Figure 6-2: A single service process can host many services.
Figure 6-3: Sessions can have multiple window stations, which can have multiple desktops.
Figure 6-4: The ActiveX Installer Service configured to allow you to install the Adobe Flash Player
Figure 6-5: After the ActiveX Installer Service has been configured to allow installation, the user gets a simple installation dialog box.

Chapter 7: Vista Client Protection

Figure 7-1: A manual MSRT scan in progress
Figure 7-2: MSRT informs you when it finds and removes malware.
Figure 7-3: Windows Security Center allows a user to view or configure security features.
Figure 7-4: Windows Defender performing a scan
Figure 7-5: A Windows Defender warning
Figure 7-6: Windows Defender can be configured to run scheduled scans.
Figure 7-7: Windows Defender can log to the event log when it detects changes.
Figure 7-8: Windows Defender can perform heuristic scanning as well.
Figure 7-9: Windows Defender gives information on startup programs.
Figure 7-10: One of the best features of Windows Defender is that it gives you insight into the processes inside an Svchost.

Chapter 8: Securing Internet Explorer

Figure 8-1: Internet Explorer's Protected Mode can be enabled or disabled on a per zone basis.
Figure 8-2: Internet Explorer's status bar indicating that Protected Mode is enabled
Figure 8-3: Program prompting the user to run it outside of Protected Mode
Figure 8-4: Internet Explorer's phishing filter detecting a known phishing Web site
Figure 8-5: Internet Explorer's phishing filter warning about a possible phishing Web site
Figure 8-6: Microsoft's phishing filter online reporting form
Figure 8-7: Microsoft's phishing filter online reporting form challenge
Figure 8-8: Internet Explorer's Manage Add-ons feature
Figure 8-9: Internet Explorer detecting an installed incompatible Add-on application during startup
Figure 8-10: Internet Explorer detecting a Web site's invalid digital certificate
Figure 8-11: Example CardSpace entries
Figure 8-12: Internet Explorer security zones
Figure 8-13: Adding a Web site to the Local intranet zone
Figure 8-14: Internet Explorer asking for confirmation before letting a Web site use the Clipboard for pasting operations

Chapter 9: Introducing IIS 7

Figure 9-1: Representative example of a directory traversal attack
Figure 9-2: Example of clear text password caught in HTTP traffic
Figure 9-3: Installing IIS Features
Figure 9-4: Default IIS Web site
Figure 9-5: Default IIS application pools
Figure 9-6: Choosing between managed and unmanaged environments
Figure 9-7: Setting a custom application pool identity
Figure 9-8: Example of IIS 7 running multiple web applications, with a range of components
Figure 9-9: IIS Manager
Figure 9-10: IIS Manager with feature delegation option selected
Figure 9-11: Choosing the default delegation state
Figure 9-12: Configuring IIS Authentication option
Figure 9-13: Choosing IIS Authentication method
Figure 9-14: Enabling Web Application pool identity instead of IIS Anonymous User
Figure 9-15: Configuring the ASP.NET Impersonation setting
Figure 9-16: Selecting Handler Mappings in the IIS Manager
Figure 9-17: Choosing the appropriate Handler permission
Figure 9-18: Choosing handler focus
Figure 9-19: Configuring HTTP verbs
Figure 9-20: The Directory Browsing Feature in IIS Admin
Figure 9-21: Modifying Directory Browsing attributes
Figure 9-22: Selecting Modules Feature in IIS 7
Figure 9-23: Enabling or disabling specific modules in IIS 7

Chapter 10: Protecting E-mail

Figure 10-1: Screensavers are basically executables.
Figure 10-2: Moving the extension away from the file is often used to fool users.
Figure 10-3: File extensions are not a good way to make security decisions.
Figure 10-4: By hovering over a link in an e-mail, you can see where the link actually goes.
Figure 10-5: Many e-mail protocols are clear-text.
Figure 10-6: Windows Mail is very conspicuous about suspected phishing messages.
Figure 10-7: The anti-phishing features can be disabled or modified.
Figure 10-8: Windows Mail contains client-side junk-mail protection.
Figure 10-9: Windows Mail contains a "Safe sender" list feature.
Figure 10-10: The "blocked senders" list may primarily be useful to block messages from people you do not want to talk to.
Figure 10-11: You may block messages from a particular TLD.
Figure 10-12: You may block messages using certain character encodings.
Figure 10-13: Windows Mail stores all e-mail messages as text files.
Figure 10-14: Windows Mail can convert all messages to plain-text.
Figure 10-15: Windows Mail preserves the original HTML content as an HTML attachment.
Figure 10-16: You can also use plain-text for all outgoing messages.
Figure 10-17: Ensure that your mail client reads all mail in the Restricted sites zone.
Figure 10-18: For sites and e-mail messages in the Restricted Sites zone, the user is prompted for her username and password.
Figure 10-19: By default, the user will not be able to access high-risk file types.
Figure 10-20: An administrator can modify the behavior of the AM using Group Policy.

Chapter 11: Managing Windows Firewall

Figure 11-1: The architecture of the Windows Filtering Platform
Figure 11-2: When configuring a firewall rule, you can also configure IPsec.
Figure 11-3: Dialog box that a user might see when an application tries to connect out
Figure 11-4: The user will almost certainly never see this dialog box.
Figure 11-5: During setup, you have to select a firewall profile.
Figure 11-6: The Windows Firewall control panel
Figure 11-7: The Windows Firewall Settings dialog box
Figure 11-8: Windows Security Center
Figure 11-9: Windows Firewall with Advanced Security snap-in
Figure 11-10: Windows Firewall settings in Group Policy
Figure 11-11: You can also configure the Windows XP SP2 firewall settings in Group Policy.
Figure 11-12: Configuring the firewall to allow connections only from particular users
Figure 11-13: Building a program rule, Step 1
Figure 11-14: Enter the path to the program you wish to control.
Figure 11-15: We will require IPsec authentication.
Figure 11-16: Restricting connections to certain computers
Figure 11-17: Configure which profile the rule applies in.
Figure 11-18: Create a server-to-server connection security rule.
Figure 11-19: Leave the end-points as "Any IP addresses".
Figure 11-20: We want to request authentication.
Figure 11-21: Click the Customize button to select advanced authentication protocols.
Figure 11-22: Select Kerberos as your authentication protocol.
Figure 11-23: Customizing a rule by interface type
Figure 11-24: You can use a WMI filter to apply different Group Policy settings based on the operating system version.
Figure 11-25: Predefined rules exist for particular services.
Figure 11-26: Configure restrictions for dynamic RPC ports.

Chapter 12: Server and Domain Isolation

Figure 12-1: You can restrict connections to only particular users.
Figure 12-2: You can now specify which authentication protocols are preferred.
Figure 12-3: Configuring IPsec rules in prior versions of Windows was anything but easy.
Figure 12-4: The initial screen on the connection security rule wizard asks you to select a rule type.
Figure 12-5: First you define which connections you require authentication on.
Figure 12-6: You can customize authentication protocols.
Figure 12-7: Set the default authentication options in the firewall properties.
Figure 12-8: Select end-points for a server-to-server rule by IP address.

Chapter 13: Wireless Security

Figure 13-1: Typical Wi-Fi setup
Figure 13-2: Manually inputting a WEP key
Figure 13-3: Manually inputting a WPA2 key
Figure 13-4: Example WPA2 setup options at the access point
Figure 13-5: Configuring a WPA2-Enterprise connection
Figure 13-6: Using WPA2 with EAP-MSCHAPv2
Figure 13-7: Instruction EAP-MSCHAPv2 to use user's default logon name and password
Figure 13-8: Configuring WPA2 to require computer certificate authentication
Figure 13-9: Network stumbler in action
Figure 13-10: Disabling SSID broadcasting on access point

Chapter 14: Using Group Policy

Figure 14-1: Create a GPO for a different user by selecting it in the Browse dialog box.
Figure 14-2: You can add several local GPOs to a single console.
Figure 14-3: To delete a local Group Policy object, follow the same steps you used to add it and right-click the object name.
Figure 14-4: The Resultant Set of Policy tools also work with MLGPO.
Figure 14-5: Using the GPMC, you can get an at-a-glance view of the GPOs in your domain.
Figure 14-6: You can now manage much of Internet Explorer using Group Policy.
Figure 14-7: Group Policy operational events are now in the event log.
Figure 14-8: Attachment Manager settings in Group Policy
Figure 14-9: Windows Vista permits administrators to control device installation.
Figure 14-10: You can whitelist specific devices or entire classes of devices.
Figure 14-11: The Windows Vista RDP client can authenticate the server you connect to. Server authentication only works with Windows Vista or higher terminal servers.
Figure 14-12: Windows Vista offers several new configuration options, such as the encryption used for RDP sessions.

Chapter 15: Thinking about Security

Figure 15-1: How many users can make an intelligent security decision based on this dialog box?
Figure 15-2: Or based on this one?
Figure 15-3: Account Lockout settings


List of Tables

Chapter 2: How Hackers Attack

Table 2-1: Common Windows Locations Modified by Malware

Chapter 3: Windows Infrastructure

Table 3.1: Vista Symbolic Links

Chapter 4: User Account Control

Table 4.1: Treatment of Built-In Administrator in Safe Mode

Chapter 8: Securing Internet Explorer

Table 8-1: Comparing Browser Market Share to The Number of Vulnerabilities
Table 8-2: Summary of Internet Explorer 7's Security Zone Settings
Table 8-3: Internet Explorer 7's Default Advanced Setting Values

Chapter 9: Introducing IIS 7

Table 9-1: IIS Versions and Platforms
Table 9-2: IIS Components
Table 9-3: IIS Authentication Method Summary
Table 9-4: Comparison of Authentication Methods Requiring Credentials
Table 9-5: IIS Resource Permission Summary
Table 9-6: Sampling of IIS 7 Security Modules

Chapter 10: Protecting E-mail

Table 10-1: File Types That Have or Can Be Used Maliciously

Chapter 12: Server and Domain Isolation

Table 12-1: List All Communications in a Table

Chapter 13: Wireless Security

Table 13-1: Wi-Fi Technology Comparison

Chapter 14: Using Group Policy

Table 14-1: New Security Options in Windows Vista
Table 14-2: Security Options with Modified Defaults in Windows Vista
Table 14-3: Security Options That Were Removed in Windows Vista

Chapter 15: Thinking about Security

Table 15-1: Strength of Passwords with Various Parameters

Appendix A: Building a Windows PE Boot Disk

Table A-1: Packages Included with WinPE


List of Sidebars

Chapter 4: User Account Control

IMPERSONATION VERSUS DELEGATION
PRIVILEGES AND RIGHTS
UTC OR ZULU TIME

Chapter 5: Managing Access Control

WINDOWS XP DEFAULT ACLS
THE ADMINISTRATOR VERSUS ANY ADMINISTRATOR
BYPASS TRAVERSE CHECKING
NOTE ON ICACLS
SAVING/RESTORING ACLS
WARNING: DO NOT EDIT YOUR SAVED ACL

Chapter 8: Securing Internet Explorer

INTERNET EXPLORER NO LONGER REQUIRED IN VISTA

Chapter 9: Introducing IIS 7

WHY DO APPLICATION POOL IDENTITIES RUN AS NETWORK SERVICE?

Chapter 11: Managing Windows Firewall

WHAT IS A SYN-ACK PACKET?
WHY DO YOU NEED A FIREWALL?
WHAT IS IPSEC?
PORTSCANNING
HOW TO SPECIFY VERSION IN WMI

Chapter 14: Using Group Policy

ELEVATION
GROUP POLICY APPLICATION INTERVALS

Chapter 15: Thinking about Security

IS PASSWORD THE RIGHT UNIT OF MEASURE?